instance spec rework: remove most dependencies on InstanceSpecV0 from propolis-server

[gjcolombo]

(Part 6/X in the instance spec rework; see #735.)

Define propolis-server's internal representation of a VM component manifest (the Spec type) and switch almost everyone in the server over to it. (The exception is the live migration preamble; this will be dealt with in a future PR that moves migration compatibility checks from api-types to server.)

• Define the internal spec::Spec type and some helper types, like internal representations of a Disk and a Nic.
  • This PR starts to show some of the benefits of this series of changes (finally!): now a regular guest VNIC, which is only ever supposed to have a viona backend, is guaranteed by construction to have one, so the machine initializer doesn't need to handle the "oops wait you specified an invalid backend type here" case.
• Add conversion functions to/from the InstanceSpecV0 public-API type. Converting to a versioned spec is infallible, but conversion from a versioned spec (which can be well-formed but not valid) is fallible.
• Represent Falcon devices with a little more care:
  • The parsed SoftNPU device collection now uses Options for components (the main PCI device, the P9 device, and the P9 filesystem adapter) with a maximum cardinality of 1.
  • When enabling SoftNPU, explicitly denote in the instance spec that SoftNPU expects to use COM4 instead of excluding it from the spec entirely.

Known warts in this change that are on deck to be fixed later in this series:

• In the new internal spec type, serial devices don't have names yet (they still use port numbers as a key and convert these to implicit names).
• The new Disk and Nic types duplicate backend names: both the types themselves and their device_spec members contain backend_name fields, and these need to be identical or hilarity will ensue. Subsequent changes will remove the backend_name field from these types and just rely on the backend name that's in the device spec.

Tests: cargo test, PHD. (It probably wouldn't hurt for me to run this in an Omicron dev cluster, either. I can give that a try before merging.)

[hawkw]

Overall, this looks great. I had some very minor nits, but none of them are major issues!