Sled views could say more about CPUs

in https://github.com/oxidecomputer/omicron/pull/8725 I'd initially included sled CPU families in the external API but upon further consideration just saying "Turin" or "Turin Dense" may raise more questions than it answers when operators are trying to use a rack. In one sense, "Turin" vs "Turin Dense" is more precise than "Zen 5", but it doesn't provide any insight into CPU topology or frequency characteristics. Because the CPU family is so limited in answering "what is actually present" I've backed #8725 out from trying to provide that for the moment.

When it comes to listing hardware information back out from sleds, one might imagine several axes of information:

• What is the actual CPU model number?
• What is the CPU's actual frequency range?
• What's the CPU topology like? How many cores to a CCD? SMT yes/no?
• What is the CPU's uarch?
• What are L1/L2/L3 cache sizes?
• What features are available, and what VMs (i.e. instance CPU platforms) can run on this hardware?

... where the "CPU family" from #8725 really only gets at that last question. Not that this all must or even should be added all at once. Some of this is available from fmtopo, some is not (yet?), so this really is several issues in a trenchcoat.

Start by reviewing PR #8725 and the hardware information available from fmtopo. Narrow the broad list of CPU model, frequency, topology, cache, uarch, and feature questions into one concrete API scope; done means that selected axis has an agreed external representation rather than the discarded CPU-family-only approach.