Strongly type differing compiler args for clarity

[AlexanderPortland]

Context

When working on #4211 & #4213, I was initially very confused by all the machinery in call_cargo.rs and call_single_file.rs that we used to pass arguments to the different layers of the compiler. The main source of my confusion was that there were many arguments all destined for different places (e.g. cargo, rustc, or kani-compiler) that all had to be encoded in differing ways (e.g. through the --llvm-args flag or the CARGO_ENCODED_RUSTFLAGS environment variable) but were mixed together sharing the same String type and similar-sounding variable names.

Although misconfiguration would often be caught at runtime with a section of the compiler complaining about unexpected arguments, this confusion silently bit me a few times where argument names were shared.

Fix

This PR represents an attempt to encode the way arguments target different portions of the compiler into the type system using specific wrapper types for each kind of argument we use. You can convert transparently into these wrapper types, but then can only convert between them or pass them to a cargo command using the proper encoding methods.

Although not perfect (you could still convert into the wrong kind of argument wrapper initially), this does seem to add some slight guardrails on the way we call cargo, especially against smaller changes to the existing patterns like the ones I was making in my PRs. It also may make the code easier to parse.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

[carolynzech]

First round of comments. Overall I am happy with this, think it's a nice improvement that makes it clearer how things work.

[AlexanderPortland]

I re-examined the code with feedback in mind (specifically the use of pass_kani_args and to_rustc_args feeling redundant) and came up with some changes.

• the redundancy was originally done out of fear that calling pass_rustc_args with PassTo::AllCrates multiple times would overwrite all but the last call (since we use an environment variable to encode the flags in that case). this turned out to be true, so I added an assertion to detect this and point to a fix.
• because of this, I thought it made sense to remove the pass_kani_args method and instead have users use the pub to_rustc_args to pass their KaniArgs into the same pass_rustc_args calls as their RustcArgs. This way, you can call pass_rustc_args(..., PassTo::AllCrates) only once on each command with all the arguments you'd like to encode into the environment variable. it's also fairly easy to just recreate the behavior of the old pass_kani_args in the few cases that it's needed.

[carolynzech]

🎉 Thanks! Excited about this

[carolynzech]

#4213 merged first, so now we get this error in the queue:

error[E0308]: mismatched types
   --> kani-driver/src/call_single_file.rs:167:24
    |
167 |             flags.push(format!("--harness {harness}"));
    |                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `KaniArg`, found `String`
    |
    = note: this error originates in the macro `format` (in Nightly builds, run with -Z macro-backtrace for more info)
help: call `Into::into` on this expression to convert `std::string::String` into `KaniArg`
    |
167 |             flags.push(format!("--harness {harness}").into());
    |                                                      +++++++

@AlexanderPortland can you merge main into this branch and update the new code so that it compiles?