VXI-11 client backend: real portmapper (UDP/111) round-trip

[ShortArrow]

Context

`src/IviCli.Backends.Vxi11/Vxi11Backend.cs:17-26`:

v1 implements create_link / device_write / device_read /
destroy_link over a single TCP connection per device. The
portmapper round-trip is deliberately skipped — ivi-cli's
gateway co-locates portmapper + Core on the same bind port,
so a real GETPORT call would only echo back the port we
already connected to. Real-portmapper-at-111 support is
deferred to v2.

Why this matters

When a user issues
`ivicli visa add psu1 TCPIP::192.168.0.10::INSTR` and
`192.168.0.10` is a 3rd-party VXI-11 instrument (not an
ivi-cli gateway), the standard portmapper handshake is required
to discover the Device Core port (the LXI standard does NOT
pin a TCP port for VXI-11 Core).

Without portmapper support, the client backend only works
against ivi-cli's own gateway servers.

Scope

• Implement ONC RPC portmapper GETPORT call (program 100000,
  version 2, procedure 3, target program 0x0607AF version 1
  for VXI-11 Device Core).
• Connect to host:111, call GETPORT, receive the dynamic Core
  port, then proceed with the standard create_link / write /
  read / destroy_link sequence on the discovered port.
• The broadcast scanner in Batch W
  (`src/IviCli.Backends.Vxi11/Vxi11BroadcastScanner.cs`) already
  speaks ONC RPC at the wire level — reuse those XDR helpers.

Acceptance

• `ivicli visa add ... TCPIP::::INSTR` +
  `visa query "*IDN?"` works against a 3rd-party VXI-11
  instrument without prior knowledge of its Core port.
• Falls back to a configured port when portmapper is
  unreachable (i.e. the v1 path is preserved as a backup).
• Update ADR 0029 in place: remove the "v2 deferred" caveat.