Because #[path = "..."] approach sets different file paths for the same module,
this causes issues with the normal module structure.

Add dependency `envy` to deserialize struct from env variables.
Refactor `common::InstallDir` using the strum crate.
Add `build_driver::TOOLS_DIR`.
Cargo fmt `build/pio.rs`.
Split build configuration into separate modules and structs `BuildConfig`, `NativeConfig`.

This change allows the build configuration to be specified in the `package.metadata.esp-idf-sys`
table of the root crate's manifest (Cargo.toml). If no root crate exists in the workspace the crate
with the name equal to the `ESP_IDF_SYS_ROOT_CRATE` environment variable is used.

All configuration specified via environment variables will override the corresponding options
of the cargo metadata. If `cargo metadata` fails for some reason, this will only generate a warning
in the build output and not cause the build to fail.

Add build dependency `cargo_metadata`.

Makes it possible to specify extra components in the `package.metadata.esp-idf-sys.extra_components`
array in the root crate's manifest as well as all direct dependencies.
This change also instructs cmake to build all extra components, but without generating any bindings.

Because cmake already knows all the compiled components, it is just a matter of forwarding
that information to the build script. This removes the need to recurse into every subfolder of
the esp-idf's components folder.

There are two ways the bindings are generated.

The first is when `bindings_module` is not set. In that case the header
of the extra component will just be added to the normal esp-idf bindings
generation. All additional bindings will also be in the root of `esp-idf-sys`.

The second: when `bindings_module` is set. For every unique `bindings_module`
bindgen will be invoked to generate the bindings, which will then be appended as a new
module to the `bindings.rs` file. Note though that since this is a new bindgen invocation
duplicate symbols of the normal esp-idf bindings may be generated.

cargo metadata resolves all dependencies even ones that are disabled (known as weak dependencies)
which cargo build doesn't do (see issue rust-lang/cargo#10801). These unresolved dependencies require
network access to load their package metadata.
As the `--frozen` flag itself blocks network access (in addition to blocking changes to the Cargo.lock)
too, we need to remove both the `--frozen` and `--offline` flags. Doing this allows cargo the change the
`Cargo.lock` though, which is undesirable (as we're in the process of building the same dependencies that
rely on the `Cargo.lock` in the first place).