New CMakeDeps

[memsharded]

Changelog: Feature: New CMakeDeps generator activated by tools.cmake.cmakedeps:new conf with value will_break_next for evaluation. This new generator deduces or use cpp_info.location/link_location to define STATIC; SHARED, INTERFACE imported targets. It will also define the IMPORTED_LOCATION, the IMPORTED_CONFIGURATION, etc.
Changelog: Feature: Use cpp_info.languages, that default to the recipe languages to propagate "link-language" requirements to consumers of the packages.
Changelog: Feature: Define cpp_info.default_components for the new CMakeDeps generator only.
Changelog: Feature: Model cpp_info.exes field for executable applications, used only by the new CMakeDeps generator, that generate IMPORTED executable targets in CMakeDeps for cpp_info.exes.
Docs: Omit

Close #7240
Close #13560
Close #16990
Close #16688
Close #12012
Close #12180
Close #14606
Close #17018
Close #16324
Close #14607
Close #9033

TODO: Close #17224

[samuel-emrys]

What are the interface implications of this new generator? It seems like it will break any invocation of find_package(XYZ REQUIRED MODULE) - are there other cases where behaviour of this deviates from the existing CMakeDeps generator and would introduce a breaking change? Should I expect for this to "mostly" be substitutable for the existing CMakeDeps generator?

[memsharded]

It is not intended to break them, it is just that at this first iteration it is not implementing MODULE, and focusing on a correct behavior for Config.cmake files, which is the most important use cases. Modules will follow in next iterations. It is not a deviation, it is a functionality not implemented yet, the intent is that it can be a replacement of the previous generator in most cases, and also fully transparent in most cases.