Generate getSwiftRuntimeCompatibilityVersionForTarget from

RuntimeVersions.def.

This really *ought* to be NFC, but alas, there are two behavior changes.
The first is that arbitrary future versions (short of the special future
version of 99.99) used to be considered to be free of all deployment
issues, but are now just considered to offer the Swift release that's
attached to the last known release of the target platform. The old behavior
was fine in a sense: deployment issues require updating the compiler anyway,
so if you haven't taught the compiler that iOS 31 provides Swift 8.3, you
probably also haven't taught it about any problems that are fixed in
Swift 8.3. The only problem with this logic is that we often implement
compiler fixes for these deployment issues before that first OS actually
ships (and thus before we've settled on a release number), and so we end
up with a race where we start considering new releases to fix the issue
even without updating the release mapping. The new approach fixes this:
we say that the bug will be fixed in Swift 8.3, and for the time being,
there are simply no platforms that provide that fix yet. Later, we update
the mapping to say that iOS 31 provides it, and compilations targeting that
release will be able to take advantage.

The other issue is that we actually treated "future" releases of macOS 10.x
(starting with 10.16, which ended up being 11.0) the same way, instead of
treating them logically as intermediate between 10.15 and 11.0.

My initial attempt at this generation used a constexpr array of a struct
with a std::initializer_list of platform releases, exactly mirroring the
structure of the .def file and requiring the compiler to parse out the
bits relevant to the target dynamically. The approach I ended up with is
much better, but I was actually forced into it because MSVC miscompiled
those global "temporary" arrays --- they ended up uninitialized.

Author: rjmccall