Add SKU number and family to the SMBIOS type 1 input

[sion42x]

Follow up to #1200 per discussion in comments.

The type 1 input covers 4 fields, but the table also defines SKU and Family per DSP0134 7.2. Today we emit those empty and they can't be set. This PR adds optional sku_number and family to the input and plumbs them to the emitted table. Both default to unset.

Per RFD 619 this is a new API version. Worth reviewing: downgrades are lossless-or-fail, which may or may not be the desired method.

[sion42x]

Worth mentioning I used (6, NVME_WRITE_CACHE) as a template for most of this, which was perfect since it also added one new optional field. https://github.com/oxidecomputer/dropshot-api-manager/blob/main/guides/new-version.md was also helpful, thanks @sunshowers

[sion42x]

Interesting chicken and egg issue I'm not sure how (or whether) to resolve, the phd-run-migrate-from-base failure requires 7.0.0 to test 7.0.0. I guess the PHD side should pin version to the max supported by the base rather than the PR?

[zeeshanlakhani]

Leaving a few comments / fixins here before we bring this upstream.

[rmustacc]

What are the intended customer semantics of these new SMBIOS fields? How are they going to be populated and interpreted?

[sion42x]

@rmustacc the goal was to keep this semantics free in propolis while writing the values into the table per DSP0134 (but emitted as empty when unset). Nexus (nexus/src/app/instance_platform/mod.rs) and sled-agent (sled-agent/src/instance.rs) explicitly set smbios: None. A customer guest could read them but we're not defining any Oxide contract.

The only intended producer/consumer pair is virtual test platforms, and a4x2 has used the table for a while now. A regression in #1178 dropped the SMBIOS input which broke sled identity and rack setup for a4x2. This PR's parent (#1200) fixes that. Since it was being corrected, I added this PR to make the table more complete against the spec. The new fields allow the emulator to declare the platform role (e.g. marking softnpu-based scrimlets for oxidecomputer/omicron#11202). Today nothing in omicron reads the new fields, and the existing type 1 fields are only read in sled-agent's SMBIOS read path which is gated on the a4x2 manufacturer string.

If I'm missing something or we'd rather not bump API version for a one-off a4x2-only change, let me know. At present, omicron can still infer the role from the existing manufacturer field (or funny enough, from the fact it's set at all).