Skip adapter rename when set-name is not explicitly provided

[maxpain]

Summary

When using network-config v2 with match.macaddress, cloudbase-init renames the network adapter to the ethernets dict key name. This causes failures on Windows:

1. WMI race condition — MSFT_NetAdapter.rename() succeeds but the new name is not immediately queryable by subsequent WMI calls, causing "Network interface with name '...' not found" errors (Network interface renaming is not working on Win Server 2022 Core #101, WMI issue may break cloudbase-init adapter rename at VM node bootstrapping  #151)
2. Rename hangs — netsh-based rename can hang for ~9 minutes on Windows Server 2022 (Windows Server 22 deployment stuck at renaming NIC #82)
3. Name collisions — renaming fails with {Object Exists} when another adapter already has the target name

This PR aligns cloudbase-init behavior with cloud-init (Linux), where the ethernets dict key is an opaque identifier when match is present, and only set-name triggers an actual rename.

How it works

The v2 parser stores link.id = dict key and link.name = set-name (or dict key if not provided). When link.id == link.name (no set-name), the adapter found by MAC is used with its current Windows name. When link.id != link.name (set-name was explicitly provided), rename proceeds as before.

Example

# Before this fix: renames "Ethernet" to "vdpa0" (unreliable)
# After this fix: uses "Ethernet" directly, no rename
version: 2
ethernets:
  vdpa0:
    match:
      macaddress: "00:00:00:00:88:01"
    addresses:
      - 10.0.0.1/24

# Explicit rename still works with set-name:
  eth0:
    match:
      macaddress: "00:00:00:00:88:01"
    set-name: my-nic
    addresses:
      - 10.0.0.1/24

Testing

• Added unit tests for both paths (no-rename and rename-with-set-name)
• All 23 existing tests pass unchanged
• Verified on Windows Server 2025 with vDPA (mlx5_vdpa) + Cloud-Hypervisor: network auto-configured on first boot from sysprepped image