CMake-first build

[ivmarkov]

@N3xed:

These changes are addressing the TODO (and this issue) where we did not support building the esp-idf-sys from mixed Rust/C projects, where the build is driven by cmake (as opposed to cargo).

The changes are as minimal as it gets, where the only new concept I had to introduce is the notion of EspIdfComponents. This was necessary, because the CMake-first builds (unlike PIO- and native- driven cargo-first ones and unlike the PIO-first ones) do NOT by default include all ESP-IDF components as part of the build). Therefore, we needed another set of cfg-s - similar in spirit to the kconfig ones, which are telling us which ESP-IDF components are part of the build. So that we can conditionally include the relevant headers in bindings.h, as well as use these cfg-s downstream to conditionally enable/disable Rust safe wrappers for those components in esp-idf-svc and esp-idf-hal.

I also took the freedom to move all build files into a build/ sub-folder, as they grew again a bit.

UPDATE: As for the changes necessary for CMake ESP-IDF projects so that these can take advantage of the CMake-first build of esp-idf-sys, look here.

[ivmarkov]

And no idea why it says there are conflicts. :)

[N3xed]

Only some small things, otherwise looks good to me.

The branch is not up to date with master (because of my last commit). That's why there is a conflict.

[ivmarkov]

@N3xed: All feedback addressed in the latest PR.
One more change: I rewrote the code where the ESP-IDF components' names are pushed as Tristate kconfig values, because these things are not really kconfigs so modelling them as such is a bit dirty. They are now directly pushed as Rust cfgs (and Bindgen -D clang_args), bypassing the kconfig layer.