As we abstract aware the env variables, users can't do a good job of
reporting these, so we'll do it ourselves.
We could make the traits public and take and explicit `env` parameter.
I figured we can wait until there is a motivating use case.
`build_env` does have a fancier `Env` impl where you pass it HOST and
TARGET and it automatically looks up values for those with a fallback
scheme.
This may look redundant with `CARGO_FEATURE_<CASE_CONVERTED_NAME>=1`
except that doesn't provide a lossless way of getting the names, e.g. for
forwarding for child builds like tests that need to build examples.
This also makes things more consistent as users
conditionalize on features through `cfg` and this even fits with what
the `CARGO_CFG_` docs say:
> For each configuration option of the package being built, this
> environment variable will contain the value of the configuration, where
> <cfg> is the name of the configuration uppercased and having -
> translated to _. Boolean configurations are present if they are set, and
> not present otherwise. Configurations with multiple values are joined to
> a single variable with the values delimited by ,. This includes values
> built-in to the compiler (which can be seen with rustc --print=cfg) and
> values set by build scripts and extra flags passed to rustc (such as
> those defined in RUSTFLAGS). Some examples of what these variables are:
Fixes#3702
Our MSRV is much higher than 1.77. Also, as time goes on, there is less
incentive to drop it below 1.77, especially with the MSRV-aware resolver
in 1.84
