vmspawn: prepare QMP infrastructure for runtime block-device hotplug (#41763)

  The block-device hotplug work (#NNNNN) needs a number of cross-cutting
  changes to the QMP plumbing that aren't hotplug-specific in
  themselves: a refcounted DriveInfo so async stage callbacks can keep
  slot refs, a counter-based naming scheme so multiple drives can share
  the same backing path, pipelined remove-fd so QEMU's fdsets get
  released at blockdev-del time, and a generic-completion callback that
  doesn't tear the VM down on a runtime QMP error. None of these change
  behaviour from a user's point of view, none of them depend on the
  varlink hotplug methods landing, and several are wins on their own
  (the fdset leak in particular is observable today with --extra-drive
  under long-running VMs). Pulling them out of the hotplug PR keeps
  that PR focused on the IDL + server-side method handlers, and lets
  this preparatory work land on its own merits without waiting for the
  larger feature review.

  Cleanup pieces that fall out for free:

    qmp-client: widen next_fdset_id to uint64_t
    vmspawn: move VMSPAWN_PCIE_HOTPLUG_SPARES to vmspawn-qmp.h
    vmspawn-varlink: use error < 0 in async QMP completion callbacks
    vmspawn-varlink: simplify on_qmp_describe_complete result extraction
    vmspawn-varlink: extract notify_event_subscribers from on_qmp_event
    vmspawn-varlink: treat empty event subscription filter as catch-all
    vmspawn-qmp: pass bridge to on_cont_complete via invoke userdata

  Infrastructure the hotplug add path will sit on top of:

    vmspawn-qmp: convert DriveInfo to a refcounted object
    vmspawn-qmp: derive QMP node and device ids from a bridge counter
    vmspawn-qmp: pipeline remove-fd after each blockdev-add
    vmspawn-qmp: keep the event loop running on post-setup QMP failures
    vmspawn-qmp: add the hotplug-capable block-device add machinery
    vmspawn-qmp: add vmspawn_qmp_remove_block_device

  The two final commits introduce vmspawn_qmp_add_block_device() and
  vmspawn_qmp_remove_block_device() but leave them without varlink
  callers — the io.systemd.VirtualMachineInstance method handlers that
  forward into them land with the rest of the hotplug PR. Boot-time
  drive setup is rewritten on top of vmspawn_qmp_add_block_device() so
  the hotplug and boot paths share a single staged-add pipeline from
  day one.