Better understanding of cfg attributes to skip excluded code

[sourcefrog]

General interpretation of cfg conditions seems difficult but we could at least skip #[cfg(windows)] on Unix and so on. At the moment they are mutated and reported as missed.

This could perhaps use https://docs.rs/cargo-platform/0.1.2/cargo_platform/.

Cargo also seems to expose cfg variables to build scripts, but perhaps not otherwise. This might not be usable. https://doc.rust-lang.org/cargo/reference/environment-variables.html

https://docs.rs/target-spec/latest/target_spec/ exists and might be useful.

[sourcefrog]

An interesting test of this would be https://github.com/rbtcollins/fs_at which on Linux finds missed mutants only on Windows.

This example indicates a couple of wrinkles, in https://github.com/rbtcollins/fs_at/blob/main/src/lib.rs#L22:

1. Rather than the module or individual functions having a #![cfg(windows)], it's the mod that includes them including module. Currently cargo-mutants doesn't look at mod statements at all, but rather it just reads everything. Maybe it would have to.
2. And, it's not even a simple #[cfg(windows)] but rather a cfg_if macro, though perhaps it could be rewritten.

Maybe there is a way to get the "preprocessed" expansion of cfg lines or even macros and look at that...

We could use --emit mir and then scrape that to try to determine which functions occur in the result.

[sourcefrog]

https://github.com/stacks-network/stacks-core/blob/8235472058e1a981f3badb7e897e418281a80ec5/clarity/src/vm/mod.rs#L44-L45

is an example of where it would help to understand cfg booleans like any, and even features.

#[cfg(any(test, feature = "testing"))]
pub mod tests;