sql: introduce new syntax to set the cluster version

[irfansharif]

After #56480 lands, we'll have completely disconnected the version setting from the usual gossip-backed cluster settings infrastructure. #56480 introduces crdb internal RPCs to bump version gates on each nodes, instead of waiting on gossip updates carrying information about version changes. Given that it is effectively no longer a cluster setting internally, we should stop pretending it is so externally.

Strawman syntax:

wtvs@wherevs> SHOW ACTIVE VERSION;
  version
-----------
  20.2
(1 row)

Time: 3ms total (execution 2ms / network 0ms)

wtvs@wherevs> SET ACTIVE VERSION = '21.2';
SET ACTIVE VERSION

Time: 4ms total (execution 4ms / network 0ms)

Doing so will lend to some much needed code simplification within crdb. It's also better UX for our users, I think. Our existing version "setting" is way more than a setting. It drives a lot of machinery under the hood, enables feature gates, and is a crucial part of cluster upgrades. It stands out relative to our other cluster settings (which very much are "just settings"), and can't be simply changed around willy nilly. Doing the above will make our documentation around cluster upgrades easier to follow, where we can then introduce just this one additional concept (the active version) instead of sneaking it in with cluster settings and its gossip backed distribution mechanism.

One additional thing to note here is that in 21.1, setting the active version will kick off arbitrarily long running migrations within crdb (see #48843). These things, like the name suggests can take a super long time to wrap up, and the statement above (and the existing SET CLUSTER SETTING version statement today) is not expected to return until it's completed. Users will be able to introspect progress through a systems table (similar to how jobs are exposed). Given that this is "new" behavior, I think serves as evidence that we should motivate it by introducing new syntax to match. +cc @tbg, @knz.

---

Randomly assigning it to our SQL experience team, which is where I think this belongs.