API review and ongoing API quality controls

Meta issue to represent some goals that @stephentoub and I discussed:

1. Before GA, we need to do an exhaustive review of all our APIs, including all the codegenerated RPC ones
- We might primarily pick one language as a representative - one that has good tooling for doing API reviews (so, C# then), and go through that end-to-end. For other languages we'd carefully review the most mainstream non-code-generated APIs but not re-do the review for codegenerated RPC.
- The goal here is to identify names, shapes, and patterns that feel wrong or that we might not want to support in the long term
- We know that a pretty large `rpc.*` API surface has appeared quickly and it hasn't been consistent about which things are flagged as experimental or not
2. Before/beyond that, we want to be more organized about reviewing new RPC APIs that arrive with each runtime update
- Proposal: the automation that updates `@github/copilot` and re-runs codegen should also output a cleanly readable list of all API additions/changes. We can ask it to flag breaking changes to non-experimental APIs too, but won't 100% rely on it detecting them. We will review the API changes as part of merging the PR that does a runtime update. This will entail extra effort for the first language we update for each runtime bump, but hopefully will be almost a no-op for subsequent languages.
3. After the [big naming change](#1043) goes in, @stephentoub will look at extending the type metadata in the JSON schema to let us map to more idiomatic types in each language (example: timespans)