need infrastructure for client-side-versioned APIs

Details in RFD 567.

Until we implement this, changes to client-side-versioned APIs risk breaking during a self-service update. That means we need to be careful to change such APIs only in backwards-compatible ways. This is something we've tried hard to avoid imposing on ourselves at development-time but doing that in these cases requires having implemented RFD 567.

This currently affects the following APIs (sourced from cargo xtask ls-apis check):

• Bootstrap Agent (bootstrap-agent-client, exposed by omicron-sled-agent). Reason: depends on itself (i.e., instances call each other).
• Wicketd Installinator (installinator-client, exposed by wicketd). Reason: client is provided implicitly by the operator in the TUF repo that they upload to the system.
• Nexus Internal API (nexus-client, exposed by omicron-nexus). Reason: Circular dependencies between Nexus and other services.
• Crucible Repair (repair-client, exposed by crucible-downstairs). Reason: depends on itself (i.e., instances call each other).
• Repo Depot API (repo-depot-client, exposed by omicron-sled-agent). Reason: depends on itself (i.e., instances call each other)

Start with RFD 567 and run cargo xtask ls-apis check to understand the five affected APIs: Bootstrap Agent, Wicketd Installinator, Nexus Internal API, Crucible Repair, and Repo Depot. The work is complete when the RFD 567 infrastructure supports these client-side-versioned APIs and avoids breaking self-service updates.