firmware: want more distinctive boot option names

the UEFI boot options for disks are named UEFI , UEFI 2, UEFI 3, and so on. in some circumstances, like the EFI shell, it's a bit difficult to get at the disk's serial number, which is where i'd find a prefix of the disk's name as known in the control plane. in other circumstances it's just hard to correlate options f.ex from efibootmgr with what disks they refer to.

EDK2 includes logic that would distinctively name NVMe devices by their model and serial numbers, but because we provide a model number containing nulls, the serial number ends up not included at all, and the auto-determined description is just UEFI . i've described this procedure in (excruciating) detail over in this test about it.

as-is we provide a serial number and not a model number (see this nvme list output from a real instance). if EDK2 were changed to replace nulls with spaces when copying model/serial number fields in BmGetNvmeDescription , BmEliminateExtraSpace would collapse runs of extra spaces and we could have nice boot option names like UEFI your-disk-name-here. or we could figure out what a full 40-character model number could be for our emulated NVMe controllers, and the stock OVMF build would be sufficient.

nice as this may be, we must not change boot option descriptions without doing something like https://github.com/oxidecomputer/propolis/issues/787, handling UEFI variables more intentionally as described towards the end of RFD 470, or having a compatibility procedure to leave old VMs unaffected. if a VM is booted and boot option descriptions change from options stored in its UEFI boot variables (which may be preserved in guest disks' EFI System Partitions), real bootable disks may end up after the EFI shell and leave affected VMs in a state like Omicron#5112

Start with the referenced EDK2 entry point, BmGetNvmeDescription, and the detailed test discussion in pull request 788. Review issue 787 and the compatibility guidance near the end of RFD 470 before deciding on an approach. Done means disk boot options are more distinctive without reordering or invalidating existing VMs' UEFI boot variables.