Reduce darling's impact on build time

[Ted Driggs]

darling's impact on build times is cited as a reason not to use it for parsing the #[wasm_bindgen] macro in [this comment]. darling should try to be a "zero-cost abstraction" for those who use it, which includes minimizing build time impacts from its usage.

Goals/Parameters

1. Minimize build time over using syn with the same features darling needs.

Since syn is the de facto standard for Rust parsing, counting it in darling's build times doesn't make sense; long syn build times should not count against darling, and improvements in syn's build time should not count as progress for darling.

2. Don't make crate authors choose between build times and customer-facing functionality

This project should first look for improvements that are invisible to users of darling, before exploring any cargo features for reducing build time. However, if/when we do explore those, we should minimize flags that impact the experience of developers who are using crates that rely on darling.

The suggestions feature appears to be an example of what not to do here, but in reality that feature was introduced because strsim had a higher MSRV than darling at the time of the feature's introduction.

Current Timings

Here is the output of cargo clean && cargo build --release --timings; remove the .txt extension and then locally open the file to see the results.

Here is the stderr output of running RUSTFLAGS="-Z time-passes" cargo +nightly build.

[daxpedda]

Unfortunately there isn't much to read into this @TedDriggs, as far as i know.
Basically blue means building and purple means code generation, like macros and proc macros, which means that some dependencies can start compiling even though their dependencies are still generating code.

The usual things to do in cases like this is to split your crates into parts that can more easily be gated behind features and enabled as necessary. Very carefully auditing your dependencies and the features you enable on them might also reveal some easy gains.

Matklad made an excellent blog post about this topic: https://matklad.github.io/2021/09/04/fast-rust-builds.html.
The blog post also dives into monomorphization and how it can significantly impact your build times.