Map CD-style numeric versions back into something meaningful to users

Version numbers are user-facing: they appear in various log and exception messages that explain to the user why the action they are trying to take is invalid given the version(s) of Elasticsearch nodes observed in a cluster.

We have recently separated out the user-meaningful `Version` constants into several independent version sequences in order to track the different aspects of compatibility to better support continuous delivery. Each different kind of version now renders as a simple integer, because the `major.minor.patch` structure does not make sense under continuous delivery.

The trouble is that these integers are meaningless to users in a traditional (discontinuous?) delivery environment, and this is rather harmful to supportability. Previously users would see some message indicating that say `8.10.3` was incompatible with what they were trying to do and they'd know they were in the middle of an upgrade and just needed to wait until the cluster was all on `8.10.4`, but now they see version numbers like `8520000` and have no realistic way to map that onto a particular release version without opening a support case.

Can we fix up the user-facing versions in released versions so they map back onto user-facing version numbers?

Relates ES-6958.

No files, tests, or entry points are named. Start by tracing the user-facing log and exception messages that report Elasticsearch node version compatibility, then inspect the independent version sequences used for continuous delivery. Done means released-version values shown to users map back to meaningful release version numbers.

Written by the indexing model from the issue text.