server: read host CPUID values if the spec has none

[gjcolombo]

The cpuid field in an instance spec's board is optional. If it is None, have propolis-server read bhyve's default CPUID values and insert them into the spec as though the caller had specified them. This has two benefits:

1. propolis-server can set up CPUID values in the hypervisor leaf range without requiring callers to set CPUID values in the standard and extended ranges.
2. When a VM migrates, the default CPUID settings from the source will transfer to the target, even if the target host's bhyve supplies different default CPUID values than the source host's.

Tests: cargo test, PHD, ran cpuid in a Debian 11 guest to check that the correct value appears in leaf 0x40000000 (and that other leaves have their expected values).

Fixes #835.

[gjcolombo]

When a VM migrates, the default CPUID settings from the source will transfer to the target, even if the target host's bhyve supplies different default CPUID values than the source host's.

@iximeow reminded me in DMs that this property was already ensured by the state export/import logic for vCPUs, so this point rings hollow (and I'll remove it from the final commit description).

Putting realized CPUID values into the spec does still have the advantage that it will appear in VM initialization logs and in the output of the instance GET endpoint, which is a least a little bit nice for observability and setting up reproductions of badly-behaved VMs. But for the most part this change is useful because it provides a path to setting up enlightenment leaves without adding additional "okay but what other CPUID values do you want?" burden to the control plane.

[iximeow]

yeah, "we already do this for migration" aside, seems like a good change.

we also discussed in DMs that we'll be setting CPUID bits for each vCPU twice in the migration path (once initializing the CPU, then once applying the migrated state), which is all at once: linear in time with the number of vCPUs, probably applying mostly-redundant state on migration, and only different from the status quo in that we'll always have two CPUID sets to apply on migration instead of only sometimes.

i'd expect that to be on the order of single-digit milliseconds for a migration at worst, so it won't be too remarkable right now but.. would be nice to not do. on the other hand, having a bunch of conditional logic for "initialized via migration" and not would be much more unfortunate. so it's not even clear what to do with that if we wanted to.