Support arbitrary toolchain versions in build.rs

[joshlf]

In order to lower our MSRV as far as we'd like, we will be losing access
to some features that we currently use. Some of these features cannot be
simply worked around, and impose limitations on what APIs we can support
(for example, what trait bounds can exist on const fns).

This commit works around this problem by introducing a general-purpose
framework for detecting the toolchain version at compile time, and
conditionally compiling code based on whether or not the toolchain is
recent enough. This ensures that no user code will break. In particular,
at any given time, if our MSRV is version N, then all code we publish is
compatible wtih version N. If, later, we lower our MSRV to M < N, we can
ensure that all functionality from the old version of zerocopy is still
present when compiling on versions at least as recent as N. We know that
none of our old users had an MSRV lower than N since they were using
zerocopy with an MSRV of N. Thus, publishing a new version in which some
features are not available on versions lower than N is not problematic
for existing users.

This approach introduces a new degree of freedom that we need to be sure
to test in CI. Previously, in CI, we tested on the MSRV, stable, and
nightly toolchain versions. Now, our behavior can differ on an arbitrary
number of toolchains, and we need to make sure to test on every such
toolchain. To accomplish this, we put the source of truth for these
versions in Cargo.toml. We introduce a build.rs file which parses
these versions and emits --cfg variables which can be used by our Rust
code. We update cargo.sh to be able to make use of these versions, and
add every such version as a toolchain to test in CI. Finally, we add a
CI job which parses Cargo.toml and .github/workflows/ci.yml to
ensure that every version listed in Cargo.toml is tested in CI.

In order to test this framework, this commit lowers our MSRV to 1.58.0.

Makes progress on #554

[jswrenn]

Figure out how to handle UI test files which differ by toolchain (do we also need N of these?)

This is almost certainly a job for the ui-test crate.

[joshlf]

Figure out how to handle UI test files which differ by toolchain (do we also need N of these?)

This is almost certainly a job for the ui-test crate.

My current solution (just pushed) is to just skip UI tests on toolchains other than MSRV, stable, and nightly.