split and regularise feature setup

As time has gone on, the initial set of features has expanded, and we've also learned more about use cases and needed tooling. We now have, at least, the following set of features one may select at build time:

• repo_redist
• repo_url
• omicron1
• opte
• optever
• tofino
• mfg
• stlouis
• compliance
• stress

We now know that we have a few 3 or 4 distinct use cases:

• recovery/installinator/factory programming which can either be collapsed into 1 or leave factory programming separate temporarily
• benchtop, where the "old school" tooling remains far and away the most useful way to operate
• in-rack, without control plane software
• production

We would expect that in-rack without control plane software (where compliance-pilot takes its place) will go away once upstack software matures, though that use case may also remain relevant longer for benchtop setups with Sidecars where there is a desire to more completely emulate the in-rack environment e.g. for Hubris CI.

Unfortunately, compliance-pilot while an excellent bootstrapping tool for in-rack use is not really suited to downstack benchtop investigations. There we still want to be able to set up arbitrary tooling in /data, e.g. putting dumps in /tmp is not really suitable, and so on. IOW, we had it mostly right the first time for this use case, even though this is emphatically unsuitable for anything involving control plane software (witness the sn21 debacle). So we should keep this and coalesce this into a "benchtop" feature set that is mutually exclusive with others.

omicron1, opte, and optever all seem to be essential to the production image and could be in the default feature set (removed for benchtop and bench-CI).

The stlouis feature currently controls only two things: inclusion of T6 firmware, and when building with the compliance feature, inclusion of an obsolete t6-mission service. This feature should be deleted, with inclusion of T6 firmware made universal and the obsolete service removed.

The tofino feature should be universal, as everything needed for it has landed in stlouis.

The stress feature can be rolled into the benchtop feature.

There is undoubtedly scope for futher discussion and work here to best accommodate the needs of various teams. The above probably represents primarily two points of view: someone who wants the old benchtop environment because what one gets when building with compliance is very much not desired, and someone who is looking over the OS feature gating and looking for opportunities to remove complexity that used to be needed but is no more.

Start by locating the Rust feature definitions and build configurations for repo_redist, compliance, stress, stlouis, tofino, and the other listed features. Compare their current combinations against the recovery, benchtop, in-rack, and production use cases. Done requires an agreed feature structure, removal of obsolete or redundant gates, and validation that each supported build use case still works.