[feature] expose CMakeToolchain conf to be able to set CMAKE_GENERATOR_INSTANCE

[jcar87]

What is your suggestion?

When the CMake generator is a Visual Studio one, for example Visual Studio 17 2022 (see docs https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html#visual-studio-generators), there are systems in which there are multiple instances of Visual Studio 2022 installed, for example:

• Visual Studio Community and Professional can be installed side by side
• Visual Studio Preview can be installed in addition to the "official" release

When not specified, CMake decides, as per documentation:

If the value of CMAKE_GENERATOR_INSTANCE is not specified explicitly by the user or a toolchain file, CMake queries the Visual Studio Installer to locate VS instances, chooses one, and sets the variable as a cache entry to hold the value persistently. 

Each installation of Visual Studio can have different toolsets installed:

• for example, we can have the v142 toolchain installed in Visual Studio 2022 Professional, but not in the community one
• or we could have the v143 with MSVC 19.40 installed in Visual Studio 2022 preview, not but in Visual Studio 2022 Community

So we could end up with scenarios where the Conan profiles specify settings that can only be satisfied by one particular instance of Visual Studio, but then CMake doesn't choose that instance by default.

Proposed solution:

• expose a conf tools.cmake.cmaketoolchain:generator_instance, such that if defined, conan_toolchain.cmake will contain an entry setting CMAKE_GENERATOR_INSTANCE with the value provided by the user

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

I have been reviewing #16229, but then I had recall that we had discussed this policy before:

• We don't want to add a new conf item for every CMake variable that a toolchain can defined.
• We already defined a mechanism for users to inject any custom CMake variable they want, that is, injecting their own tools.cmake.cmaketoolchain:user_toolchain
• The only inconvenience is that it is not directly encoded in a profile, but it requires a my.cmake toolchain file.

I have rejected feature requests from users very similar to this one.
What is different in this CMAKE_GENERATOR_INSTANCE that it deserves its own conf? Wouldn't the user toolchain be a viable solution?