Using FetchContent for Workspace meta-project

[memsharded]

Originally posted by @mattangus in #15992

I am experimenting with the suggestion by @mattangus in this ticket, it is looking promising, a couple of quick comments:

• The internal target names are not that common to be the same as the exported/installed ones. I am not even sure this is a CMake recommended practice, so it is likely we cannot rely strictly on this. What could be a good way do define such aliases somewhere, so they are injected dynamically.
• For external dependencies, it is necessary to do a conan install first for one of the products, then pass the toolchain to the cmake command, so the generated ZLIB-config.cmake is found. But this file can be generated differently per sub-project, this is a bit uncertain how it will work together.
• Not very clear why you comment that it is necessary to set_target_properties(project2 PROPERTIES ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}), for me it works without it.

So the initial challenges to focus are:

• Definition of alias for compatibility
• Definition of paths for different subprojects to locate their dependencies (the xxx-config.cmake files can be different)
• Definition and usage of a toolchain file if necessary

[memsharded]

Some very early stage poc: #17675

# create an external dependency to the workspace first
mkdir myproj && cd myproj
conan new cmake_lib -d name=mymath
conan create .
rm -rf *

# now the actual workspace
conan new  workspace -d requires=mymath/0.1
conan workspace install
cmake --preset conan-default # conan-release in Linux