Add guidance for migrating existing APIs (in omicron?)

[jgallagher]

Having gone through an API migration a few times in Omicron, we've seen some "good things to do" that we should document. This might be too prescriptive for dropshot-api-manager generally, but I wanted to note the need to document what we currently believe to be the best route when changing an existing endpoint:

• Add a v${N}_the_endpoint() handler, where ${N} is the last version before the change. This is the "old" handler that servers must still implement (although in many cases they may not have to implement it manually; more in the last bullet).
• Keep the current endpoint the_endpoint() with no version in the endpoint name. If we put the version in which it changed, that will get stale over time. E.g., if we update the endpoint in v7 and make it v7_the_endpoint, but then rev to v8, v9, and v10 without touching this endpoint, the current API version will be v10 but a v10 client will need to call v7_the_endpoint, which is a little confusing.
• If the types of the inputs/outputs to the endpoint change, update the common/shared types in place, and add a new v${N} module with the types needed for the old v${N}_the_endpoint() with as reduced visibility as we can. In the simplest cases when it's possible to impl From<OldType> for CurrentType, this module can even by private in the API crate, and the dropshot server API trait can provide a default implementation for v${N}_the_endpoint() that converts the types and calls the current endpoint.

oxidecomputer/omicron#9407 is an example of updating an API change to follow these guidelines.