Introduce locked versions for top-level resources

[mikhailshilkov]

A very simple approach to fix #512

Basically, the suggested default mode of operation:

• When a new API version comes out, we'll update our top-level resources to it automatically (that already works)
• We manually review every update for code-level breaking changes (I already do, see e.g. Breaking changes in API #127)
• If the review identifies that a new version brought a breaking change, we add an entry to the lockedTypeVersions map below and re-run the generation
• We assume that the new API version doesn't bring service-level breaking changes that we would want to avoid. We don't really have a way to test for this, so our options are a) take all new versions and rely on MS not breaking the behavior b) don't take any new versions at all. I feel like (b) would be too detrimental to the user experience.
• Since the review is a manual process, I'm choosing to hard-code the map in code. There's no way to generate it anyway.

We may want to invest in a tool that compares two schemas and detects breaking changes. I'll open an issue once we land this PR.

We'll start applying this policy now and will still have time to learn and iterate if needed before the GA.

[viveklak]

Suggested change

	// A manually-maintained list of versions where we want to use for the top-level resource. The primary goal is to
	// A manually-maintained list of versions that we want to use for the top-level resource. The primary goal is to