Establish backward compatible way to innovate on computing version height

[AArnott]

Changing counting behavior for existing version.json files is a version height breaking change and must either be part of a major version bump of the library or perhaps a new pattern can emerge.

We already have a versionHeightOffsetAppliesTo property that is useful to delaying a version height offset to exactly the moment when the version changes in a height-resetting way.
What if we do something similar for a "version height algorithm version"? NB.GV would increment an integer each time it makes a breaking change to how version height is computed, with 1 being the current behavior as of v3.9. version.json can opt into a later algorithm version, and can express a desire to opt into a still newer algorithm as of when version.json bumps its declared version again. Something like this:

{
  "version": "1.2",
  "versionHeightAlgorithmRevision": 2
}

and to "schedule" jumping to 3 at the soonest non-breaking opportunity, this could be changed by the user to:

{
  "version": "1.2",
  "versionHeightAlgorithmRevision": [
    { "appliesTo": "1.2", "revision": 2 },
    3,
   ]
}

Or something like that.

[AArnott]

Or maybe we do something even more general, like a new while property whose value is virtually everything at the top level except while itself. This way you can condition anything to disappear after a version change:

{
  "version": "1.2",
  "versionHeightAlgorithmRevision": 2,
  "while": {
    "version": "1.2",
    "versionHeightOffset": 300,
    "versionHeightAlgorithmRevision": 1
  }   
}

This would cause versionHeightAlgorithmRevision: 1 to apply until the top-level version property changes to 1.3, after which everything in the while property loses all effect (and can be removed at the user's convenience).

The version.json parser would have to merge while with the parent object when the version property matches and ignore it otherwise. The merge policy would be that while overwrites everything in the top-level context.
Then for the original point of this issue, the versionHeightAlgorithmRevision property's value would need to be exposed to the version height computation function so that it can branch based on the revision that applies for that commit.

[AArnott]

After thinking this through, I think the property should support two forms.

For opting into a revision immediately:

{
  "version": "1.2",
  "versionHeightAlgorithmRevision": 2
}

The selected revision would govern the entire version-height calculation, including commits that predate the property. This treats the revision as the policy under which we evaluate history, rather than as another historical input that may change during the walk.

For scheduling a revision change at the next version change that resets version height:

{
  "version": "1.2",
  "versionHeightAlgorithmRevision": {
    "revision": 2,
    "appliesTo": "1.2",
    "then": 3
  }
}

Here revision 2 remains in effect while the declared version is still compatible with appliesTo for version-height purposes. Once version changes in a way that would reset height, revision 3 takes effect. appliesTo should therefore use the same "would this version change reset height?" semantics as versionHeightOffsetAppliesTo, rather than literal string equality.

I prefer this scalar-or-object shape over the array proposed above. There is only one useful transition to represent: the current algorithm and the algorithm to use after the next safe reset. An array suggests that users could or should accumulate a history of version-specific algorithm choices, but those additional entries would not be relevant to a calculation. The fixed object expresses the one supported transition directly, while retaining the convenient scalar form for users who want to change the revision immediately.

A missing property would mean revision 1 (the current behavior), and selecting an unsupported revision should be an error rather than silently falling back.

I don't think we need to implement this mechanism preemptively. We can wait until we have an actual version-height policy breaking change to introduce. Revisiting the merge/path-filter behavior discussed in #1413 may provide that need.