CMakeDeps. global target: from merging cppinfo to link component targets

[lasote]

Changelog: Feature: Changed CMakeDeps generator so the global target made for a package with components is a target linked with the targets of the components, instead of a target made from merging cpp_info objects from the components.

Changelog: Fix: The cmake_build_modules property can only be declared in the self.cpp_info, not in components, where will be ignored.

Docs: conan-io/docs#2664

Closes: #11673

[memsharded]

I'd say that further cleanings are possible, like not calling aggregated_components if there are no components, and not computing the global TargetDataContext.

But this is perfect for a first step, disabling the output and the behavior, to learn if something breaks. Good job.

[thorntonryan]

Changelog: Fix: The cmake_build_modules property can only be declared in the self.cpp_info, not in components, where will be ignored.

@lasote , out of curiosity, what was the reason for this change?

I have a draft PR internally that was actually doing a component based cmake_build_modules -- in part because introducing the components seemed to throw errors on having other global self.cpp_info properties defined. But also because each component wanted to add its own *.cmake file that defined additional target properties to the component based target. So it sort of made sense to describe this on a component level, instead of at the global level.

It'll be easy to fix. Just curious why the change was made.

[memsharded]

Because build_modules in practice cannot be "activated" per component. The CMake way of including them make them always global, per package. So it is better to make this fact explicit not allowing to define them per-component but globally.