Trust quorum should have its own Authz resource object

[andrewjstone]

Right now, trust quorum is using a combination of Fleet and Rack access as of this commit.

It should be using it's own object. In @davepacheco's words:

So, the best and most annoying thing would be:

• Define a new synthetic authz type like struct RackTqConfig(RackUuid). This is sort of analogous to SiloCertificateList(Silo) (in nexus/auth/src/authz/api_resources.rs). There's like 30 lines of boilerplate in Rust.
• Then another 10 lines of boilerplate in nexus/auth/src/authz/omicron.polar.
• Having done that, everywhere you're using a RackUuid, you'd use an authz::RackTqConfig(rack_id).
• At the datastore level, you'd be accepting an authz::RackTqConfig instead of a RackUuid and you'd be doing opctx.authorize(authz::Action::Read, &rack_tq_config).

There is a decent amount of work here, that I didn't want to cram into my open PR, as this is all about future proofing for multirack. It would also require changing the datastore tests. None of this is hard, just tedious with a touch of discovery for myself.