Add support for cargo configurations.

[Alexhuszagh]

trafficstars

Also adds support for parsing and reading configuration options/environment variables from cargo, and allows users to ignore config files in the package.

This adds the [build.env.cargo-config] option, which can be set to complete, ignore, or default. If set to complete, cross will have access to every to every cargo config file on the host (if using remote cross, a config file is written to a temporary file which is mounted on the data volume at /.cargo/config.toml). If set to ignore, any .cargo/config.toml files outside of CARGO_HOME are ignored, by mounting anonymous data volumes to hide config files in any .cargo directories. The default behavior uses the backwards-compatible behavior, allowing cross to access any config files in the package and CARGO_HOME directories. If the build is called outside the workspace root or at the workspace root, then we only mount an anonymous volume at $PWD/.cargo.

The alias support includes recursive subcommand detection, and errors before it invokes cargo. A sample error message is [cross] error: alias y has unresolvable recursive definition: x -> y -> z -> a -> y, and therefore can handle non-trivial recursive subcommands.

Closes #562. Closes #621.

Partially related to #704.

[Alexhuszagh]

This still needs to support the cargo environment variables, which luckily shouldn't be too hard.

[Alexhuszagh]

This now supports environment variables, and the design is similar to the cross configuration files (and much more logical), but avoids parsing variables except for those we know and lazily reads environment variables.

• [x] Recursive alias improvement

EDIT: This still needs some work handling recursive aliases, since it only handles recursion that is self-referential:

[alias]
recurse = ["recurse"]

This really should be able to handle:

[alias]
x = ["y"]
y = ["z"]
z = ["a"]
a = ["x"]

This would be very doable with a lookup set, which tracks each subcommand that has been seen until an unseen alias is processed. This would output something like:

$ cargo x
error: alias x has unresolvable recursive definition: x -> y -> z -> a -> x

The recursive alias support currently just uses a Vec, since we'd need an IndexMap for better time-complexity, but in practice we're unlikely to have highly recursive aliases. If needed, we could always switch to a hashmap that iterates over by insertion order.

[Alexhuszagh]

Temporarily marking as a draft since this might have undergone a bad rebase, and I don't have the time right now to verify that it's correct.

[Alexhuszagh]

This will need substantial rebases and refactoring, which I'll try to do shortly, so I'll revert this to a draft in the meantime.