Prefer component IDs to names

[iximeow]

from this conversation in #756:

propolis-server gets disk requests from Nexus with disks named by their name, likewise for NICs. these names are technically mutable, though such mutation should be disallowed by Nexus any time propolis-server might need to know. but at the same time, propolis-server derives identifiers from these names that then are used to identify those devices' backends, as in parse_disk_from_request. VNICs do a similar derivation but with PCI paths.

for disks, since name is essentially user-defined, it would be really nice to use the disk's ID instead - that has a much more structured shape that we control ("UUID", rather than "a string that Nexus hopefully validated enough for Propolis to handle responsibly").

while propolis-server could handle getting UUIDs from Nexus in the name field, this would be a breaking change for users. the disk name ends up as part of the identifier for paths like /dev/disk/by-id, so changing the guest-presented name from the name to a UUID would break paths in VMs that expect /dev/disk/by-id to be immutable. it may well be a bug that /dev/disk/by-id can be changed by renaming a disk - such an operation probably should not be functionally similar to changing a serial number of a device..

we could easily punt on the user-facing breakage here by separating the disk name, which could reasonably be presented to guests. so maybe as an interim step we should get both the disk name and ID from Nexus, and use ID in all places that would not be directly presenting the disk name to guest OSes.

for NICs, the PCI path is at less arbitrary user-defined input, but it seems like it would be nice to use a stable UUID there as well, since a VNIC's slot could change.

it doesn't seem to me that other devices have a similar issue with user-provided input being used for internal identifiers, at least.

relatedly: @gjcolombo raised that we should think through what the IDs should be for other components like serial ports. whatever IDs get used for disks and others we should make sure that GET /instance/spec is informative for debugging (might already be, i just dunno tests might apply here)