"Environmental" means to choose PROFILE_BUILD and PROFILE_HOST

[puetzk]

For the stock PROFILE, conan has a CONAN_DEFAULT_PROFILE_PATH environment variable. But this does not provide a way to do many newer conan features, like multiple profiles, or --profile:host vs --profile:build. And it's my understanding (per discussion in conan-io/conan#6476) that this is something conan itself would like to move away from in the future, so there's little appetite to add more to it.

I'd like to still see some way for IDE configurations like Qt Creator "kits", visual studio's CMakeSettings.json configurations, a custom Toolchain file, or the cmake-presets (new in 3.20) to influence the default settings/profiles used by conan_cmake_install (in general, the PROFILE_* arguments don't really make sense to hardcode into a CMakeLists.txt, since the same project is usable on many different platforms). So another idea that seems reasonable would be to have some CONAN_* CMake variables, which could be preset cache variables, set by the IDE or from a toolchain file) paralleling a lot of the non-project arguments of `conan_cmake_install

I'd propose (at least) the following as settings that a project often wouldn't know, but a preset might be able to usefully supply:
CONAN_COMMAND
CONAN_GENERATORS
CONAN_PROFILE, CONAN_PROFILE_HOST, CONAN_PROFILE_BUILD
CONAN_SETTINGS CONAN_SETTINGS_HOST, CONAN_SETTINGS_BUILD,

or prehaps these could be CONAN_DEFAULT_*, or whatever other naming scheme is preferred. These would all basically just be treated as defaults that could still be appended to (or in the case of CONAN_COMMAND, overwritten) by anything passed through conan_parse_arguments.

Admittedly, I previously filed #185 reporting one variable (CONAN_GENERATORS) that already works like this, seemingly by accident, just because the code appends without overwriting. But if intentional and documented, I think it might be a good way to get this information in without having to edit each project file to least each combination of settings it might be built with, and instead of be able to supply the conan profile used to resolve dependencies in the same place as the preset that supplied the CMAKE_TOOLCHAIN_FILE and such configuration for the consumer.

[puetzk]

Perhaps related to #307, though @uyha was more willing/able to just forward a few variables and let it re-autodetect the rest (that wouldn't work for all cases, but it's enough for simple ones where the profile/toolchain file aren't doing much more than providings settings.arch and a prefixed compiler).