nexus-types: add SupportBundleRequest type and Case field

[mergeconflict]

The core thing this PR does is:

• Introduce a new SupportBundleRequest type to fm::case (analogous to @hawkw's AlertRequest), and
• Introduce a new support_bundles_requested field to Case (analogous to alerts_requested).

There's a lot of ✨ceremony✨ around this small change, though:

• DisplayCase has a sophisticated impl Display that formats the stuff it contains. So we need Display impls for all the things SupportBundleRequest transitively contains (BundleData, etc.). Here's what this comes out looking like:

       support bundles requested:
       -------------------------
       * bundle a9b8c7d6-e5f4-3210-fedc-ba0987654321
         requested in: bba63ba7-bf6b-45f4-b241-d13ccd07fe1c <-- this sitrep
         data:         all (default)
  
       * bundle d1a2b3c4-e5f6-7890-abcd-ef1234567890
         requested in: ea7affb0-36eb-4a9a-b9bd-22e00f1bcc04
         data:
           - sp_dumps
           - ereports(classes: hw.pwr.*)
           - host_info(all)
           - reconfigurator
  

• Since Case is serde::Serialize/Deserialize, we also need to add derives to SupportBundleRequest and all the things it transitively contains.

• Lastly, since we want to have some sort of reasonable round-trip test for the serialization / deserialization, we use proptest to generate arbitrary inputs. This requires Arbitrary impls (or functions that return Strategy) for all the things too.

Context: #10062.

[hawkw]

I think that either this branch or mergeconflict/fm-sb-type-relocation (?) needs to be rebased/merge main, as it looks like there are a lot of unrelated changes in the diff here.

[hawkw]

how long do you think this list is liable to be? i always try my best to make my omdb command output 80-column-terminal friendly, because i am spiritually very old or something. i won't hold you to this particular bit of mental illness unless you find it entertaining, but if this is liable to be quite long, we might want to bite the bullet and turn it into a multi-line bulleted list or something?

[mergeconflict]

I've done a half-assed job of this in accc0bd, splitting the bundle data categories out into a bulleted list. But now I'm thinking, the two non-trivial BundleData variants can be arbitrarily long:

• HostInfo (contains a HashSet<SledSelection>)
• Ereports (contains only_serials: Vec<String> and only_classes: Vec<String>)

Do you think it's worth prettying these up too?

[hawkw]

Ehh, I dunno if I care. Up to you.

[hawkw]

This is looking pretty nice! I had a couple small nits you may want to address, but I'm good with this overall. I think we should add the builder stuff in a separate branch, if you want to do that.