The `--cfg` flag is added to the `cargo rustc` subcommand. The
implementation generally follows the `--unit-graph` implementation in
that it aborts compilation after the build context is created.

I discovered that cargo runs the `rustc --print cfg` every time it
builds/compiles a package. It stores this information for all compiler
targets and the host in the `RustcTargetData` struct, which is further
populated when the build context is created. When the `rustc --print
cfg` command is ran internally, all of the Cargo configurations and
environment variables are applied to the command. This means that the
command does not need to be re-run for the `--cfg` flag. Instead, I just
needed to print what was already populated into the `RustcTargetData`
struct for the build context and abort before executing the
build/compile job.

The existence of the `rustc --print cfg` command being executed
internally to Cargo also meant that multi-target and cross-compilation
are naturally supported. However, the output kind of has to be JSON
because it is not possible to select a single compiler target to print.
It gets messy very quickly if multiple targets are specified and which
one to use for the "human" output similar to the `rustc --print cfg`
command. The solution is to output in JSON like the `--unit-graph` flag
and include the data for the host and any specified targets. A
downstream parser can then pull out/extract the target data that is
needed.

The `--cfg` flag needs to be added to the `cargo build` subcommand, too.
The `--unit-graph` flag is available in both subcommands and so should
the `--cfg` flag for consistency. Ultimately, the `cargo build`
subcommand "calls" the `cargo rustc` subcommand. In other words, both
subcommands use the same implementation.

The flag does not appear in the help text, but the `--unit-graph` does
not either. I need to work on this as well.

…ure-rustc-cfg-argument

…ure-rustc-cfg-argument

The `--cfg` option is changed to `--rustc-cfg` for the build, bench,
test, and check subcommands but left as `--cfg` for the rustc
subcommand. The `--rustc-cfg` flag is more descriptive of
configuration (cfg) that will be printed as JSON, but it looks weird if
`--rustc-cfg` is used with the rustc subcommand, i.e.:

```pwsh
PS C:\>cargo rustc --rustc-cfg
```

versus

```
PS C:\>cargo rustc --cfg
```

By using the rustc subcommad, the type of output and configuration is
known, but wiht the other subcommands it is ambiguous what a lone
`--cfg` would output.

The name of the flag changed for some subcommands from `--cfg` to
`--rustc-cfg` but the parsing of the arguments was not updated to
account for the different names.

Following the template of the `--unit-graph` option, the `--cfg` and
`--rustc-cfg` flags are placed behind the `-Z unstable-options` flag.
Now, if the `--cfg` or `--rustc-cfg` flags are used without the `-Z
unstable-option` flag, an error message will appear. Once stablized, I
believe this requirement can be removed.

The `BuildConfig.cfg` is changed to `BuildConfig.rustc_cfg`. I am afraid
of a name collision or confusion with just a `cfg` field. The
`rustc_cfg` field indicates this is for printing the compiler (rustc)
configuration from the `rustc --print cfg` like process, instead of some
higher level or more generic "configuration" type.

Here again, the `cfg` name is too generic and could be confusing. It is
changed to `rustc_cfg` in similar convention to the `unit_graph` module
and to relate it to the `--rustc-cfg` flag.

The original format was quick-n-dirty and more like a "raw dump" of the
compiler configurations. The quick-n-dirty format would probably work
just find for 99% of the use cases but it was kind of noisy and verbose.
The target features were not great. The new format is less noisy (no
"target_" everywhere) and provides an array of the target features. It
is just more clean and elegant.

Note, there is no implementation or CLI argument to select a JSON format
version. I am not sure such an implementation is even needed.

…ure-rustc-cfg-argument

Similar to the `--unit-graph` flag, which is also hidden, the `--cfg`
and `--rustc-cfg` are hidden. I think they will be made visible once the
feature is stablized.

…ure-rustc-cfg-argument

Only the `cargo rustc --cfg` argument remains. Having the `--rustc-cfg`
flag for all other subcommands as too much and deemed not really
necessary or useful.

The `--cfg` flag is changed to `--print-cfg`, so it is a little more
obvious what the flag will do. At the same time, the implementation is
changed to only affect the `cargo rustc` subcommand. It skips
downloading the entire crate graph and compiling/building the project.
Instead, it just obtains the rustc target data similar to the
`ops::compile` function and then returns. The `ops::print_cfg` function
is added, but this could also be moved to just the `cargo rustc`
subcommand.

A static constant is used to define the arg name since this may change
after review but the string is used as an ID in processing arguments.

The JSON format does not parse or group or drop prefixes for
configurations. For each compiler target (host, etc.), the
configurations are just strings in an array. The targets is changed to
an array of maps as well.

The `--print-cfg` flag will be replaced with the `--print foo` option
and passed to `rustc --print foo`. The output will be the "raw" output
from the `rustc --print foo` command instead of a serialized JSON of the
RustcTarget Data. This is the first step in changing the implementation.
The serialization code is no longer needed.

The implementation now follows `rustc --print <INFO>` and adds the
`--print <INFO>` option to the `cargo rustc` subcommand. When the `cargo
rustc --print <INFO>` command is executed, all extra arguments are
passed to the `rustc --print <INFO>` command including the
Cargo-specific (compiler) target flags and options from Cargo's
configuration and environment variables. If multiple `--target <TRIPLE>`
options are used, then the list is of (compiler) targets are iterated
and outputed with an empty line delimiting the output for each compiler
target. If no `--target <TRIPLE>` is used, then the host compiler target
is used.

None of the output is altered. It is just a straight dump of the `rustc
--print <FOO>` command.

This implementation works with any of the `<INFO>` values for the `rustc
--print <FOO>` command, i.e. `cfg`, `target-list`, `sysroot`, etc.

Most of the arguments for either `cargo rustc` are ignored unles
recognized by the `rustc --print <FOO>` argument. For
example, `--target <TRIPLE>`. Cargo configuration is target dependent,
so the `--target <TRIPLE>` must be recognized.

Error handling is done by rustc and the stderr is simply printed. The
`rustc --print <FOO>` command is always executed instead of using the
cache.

Only printing an empty line after the first target output is changed to
use the `enumerate` method on an Iterator with a non-zero index.

I could not get the `drop_println` macro to compile. Something about the
`shell` missing. The standard library `println` macro seems work fine.

I figured out the error was me improperly using the macro. CI build
failed because `println` macro is not allowed in Cargo codebase.

…ure-rustc-cfg-argument

# Conflicts:
#	src/cargo/ops/cargo_compile.rs

…73/cargo into feature-rustc-cfg-argument

…ure-rustc-cfg-argument

The `output_err_info` function can be private now that the
implementation for the `cargo rustc --print <FOO>` command has changed
to not capture the output.

The `TargetInfo` type, but more specifically the `TargetInfo::new`
method is used instead of the making the `env_args` function public and
using it.

This means the `env_args` function can go back to being private, too.

The `exec_with_output` function and subsequent writing to stdout and
stderr is replaced with the `exec` function that inherits the stdio
streams from Cargo is used.

Weirdly, I originally tried to use the `exec` function but I go no
output. The `cargo run -- rustc --print cfg` appear to just hang. So, I
switched to using the `exec_with_output` function. Now, the `exec`
function appears to work and it is much simplier. There must have been
something else going on with my system at the time.

Not sure how to handle running the test on different hosts, so the first
test is explicit about the compile target to print the configuration.

Using the multitarget feature to print the configuration of multiple
compiler target configurations, a test is created.

The `RUSTFLAGS` environment variable is used to add the "crt-static"
target feature and test printing the target compiler configuration
contains the `target_feature="crt-static"` line.

A `.cargo/config.toml` file is used to add the "crt-static" target
feature and test printing the compiler target configuration contains the
`target_feature="crt-static"` line.

The `panic="unwind"` appears in the output for the CI tests, but not in
my local tests. I need to investigate the origin of this configuration
but it causes the CI builds to fail.

The `with_stdout_contains` was mis-used. Since some lines may or may not
appear for some compiler targets and environments (nightly, beta,
stable, etc.) the tests would fail because the output was not identical.
Instead of a using raw strings, each line with the arch, endian, env,
family, vendor, pointer_width, etc. that are known to always be
present (at least of the CI builds) are included. This should work for
the CI environments and my local environment.