instance spec rework: move migration compat checks to propolis-server

[gjcolombo]

(Part 8/9 of the instance spec rework; see #735.)

Transfer Propolis's component-level live migration compatibility checks from the API types crate to propolis-server. This is the last big chunk of application code that lives in the api-types crate. This is not straight-up code movement because the internal Spec type doesn't have the same notion of "device" and "backend" collections that the wire type has. This means that the hierarchy of errors in the new propolis-server compat.rs is different (but hopefully simpler) than what was in the old propolis-api-types migration.rs. The actual compatibility rules should be the same as they were before, however, and I've tried to bring over wholesale the api-types crate's compatibility unit tests.

Also, adjust how compatibility checks work in the migration protocol. Before, the migration preamble sent a DeviceSpecV0 and a list of backend component names; the destination checked that the devices were compatible and that the backend name sets matched (but, owing to the absence of the actual backend descriptors, did not check that the backends themselves were migration-compatible). With this change, the preamble contains the source's entire InstanceSpecV0, though the compatibility checks are still (currently) limited to the VM's devices. This breaks the protocol's dependency on the notion that instance specs necessarily have collections of "devices" and "backends" as opposed to simply having a set of components. This is a prerequisite for the next PR in this series, which removes this distinction from the InstanceSpecV0 type itself.

This is a migration protocol-breaking change, so failures in the migrate-from-base tests are expected.

Tests: cargo test, PHD.

[gjcolombo]

this doc comment doesn't need to be 500 words or anything but I could probably elaborate a little bit here

[hawkw]

Overall this looks great to me --- removing the distinction between "backends" and "devices" from the spec types is a nice simplification. I quite like the new compatibility errors, too: the messages seem a bit more helpful than the prior ones. I picked a few very minor nits but there's nothing terribly controversial here IMO.