Gateway `hardware_component` Oximeter metrics should include VPD when available

[hawkw]

Related to #11256.

Now that oxidecomputer/hubris#2650 and oxidecomputer/management-gateway-service#500 have merged, we now have a gateway-sp-comms API for reading VPD from individual components exposed by the SP. This includes PMBus devices (including, importantly, the rectifiers in the power shelf) and FRU EEPROMs, such as those on fan modules, sharkfins, and so forth. It would be nice to update the Oximeter hardware_component: sensor metrics that MGS emits to include the FRU identity that a sensor reading came from, when it's available.

After we update thegateway-sp-comms dep to oxidecomputer/management-gateway-service@438cd18 (see #11256), we should also add FRU identity to sensor metrics. There are a few notes:

• We can now read a bunch of different kinds of VPD from different kinds of devices, and they don't all fit neatly into a single "manufacturer/part number/revision/serial" schema. For example, the TMP117 temperature sensors both have VPD and emit sensor measurements, so it would be nice to have labels for the...but their VPD takes the form of a 64-bit number formed by a 16-bit device ID (0x0117) and 48 bits of NIST traceability data, which is kind of like a serial number...but we'd need to think a bit about how to fit this into a schema.
• For Oxide barcodes, Hubris is reading the raw contents of the relevant TLV-C tag(s) and not normalizing the hyphen in part numbers, so we will want to do something similar to this: https://github.com/oxidecomputer/hubris/blob/0d1ba0453a5d80470f07ea9949eb82bc3c291e01/lib/oxide-barcode/src/lib.rs#L214-L258
  before writing them to Oximeter
• PMBus devices have wildly varying contents of their PMBus VPD commands, and only a few of them actually have a serial number or relevant FRU identity. We may only want to include metric labels for things which are FRUs, such as PSUs, and not worry about adding them for things like VRMs, especially because most of the smaller PMBus components integrated on the board don't have serialization in their VPD.
• For some FRUs, such as fans, the Hubris component ID that provides sensor readings (like fan speed) and the Hubris component ID of the VPD EEPROM are different. This is also the case for e.g. sharkfin HSC sensors. We will need some knowledge of these relationships to implement FRU ID labels for those components. See also ereports: How do we identify devices we send ereports about? hubris#2673 for a similar discussion.

[hawkw]

Oh, I guess this is a duplicate of #9000, whoops. This ticket has a much better writeup of the current state of things, so I'll move all of this into a comment there.