`gimlet_sp` and RoT artifact kinds should probably be something different

Today we have three different groups of artifact kinds for images that represent SP images:

• gimlet_sp
• psc_sp
• switch_sp

These are single-unit artifacts. These artifacts have different names such as gimlet-b. When software is trying to perform an update today it matches the hubris caboose with the board name. Already today we are using a generic class of hardware for the switch and psc, but we are using a specific name for a server sled. With the forthcoming introduction of Cosmo SP images, this is only going to get more confusing. My rough guess here and some thoughts from @jgallagher was that the gimlet_sp kind was just named specifically, but should have been something more generic like sled_sp. This is somewhat reinforced that even Wicket's SpType calls this generically a Sled. There are generally four ways forward here:

1. We introduce a new cosmo_sp entry and say that server sled classes are specific. This seems the opposite of the direction that we want to go as there's actually nothing really different about the kind here.
2. We say, well the name gimlet_sp is baked and so we're just going to use that as the kind for the Cosmo SP artifacts.
3. We rename the gimlet_sp artifact to something that indicates it's the generic class of sleds.
4. We take a step back and ask what the signifier of the kind is here and what properties should actually dictate a change. This would effectively combine all of these different kinds into a single one.

An artifact kind in the current glossary draft is a well-known categorization. So given that we are using the artifact name to distinguish these, how do we figure out when there should and shouldn't be a category for something like an STM32H753 Hubris image. That is, I would question why even have different categories for these at all. The thing that seems to be the unifying pieces here seem to be:

• The correct artifact and deployment unit can be determined by matching the caboose board property.
• We are assuming there is a single archive that we need to pick.

Similarly the RoT and RoT bootloader have their own unique properties that make it clear that these all should be different artifact kinds. But it's not really clear to me that every class of hardware should, until we change something about these properties. For example, say we had an RoT that was based upon some other microcontroller that had the option of banked flash and therefore we had a very different way that the actual artifact was packaged and how we selected it, it follows that the artifact kind would have to be different. Conversely say we had a different generation SP hardware but it had the same single-unit nature, then there's no reason we probably couldn't reuse the same artifact kind since the way we would select and extract it would be the same.

I think this all leads me down towards (4) and that perhaps that the general kind is broader than we have used to date for the SP, RoT, and RoT bootloader. We should probably at least do (3) here, though I think we should consider (4) more strongly and what properties actually make sense here.

Start with the current artifact-kind glossary draft and Wicket's generic SpType/Sled terminology. Compare gimlet_sp, psc_sp, switch_sp, RoT, and RoT bootloader kinds, including selection by caboose board property and archive packaging. Done means reaching a decision on the category boundary and documenting or applying a consistent naming scheme, including the forthcoming Cosmo SP case.