CMakeDeps managing CMAKE_MAP_IMPORTED_CONFIG_XXX

[lasote]

Changelog: Bugfix: The CMakeDeps generator was not working properly when the consumer maps configurations of the dependencies using CMAKE_MAP_IMPORTED_CONFIG_XXX.
Docs: conan-io/docs#2826

Close #12041

[memsharded]

Looking good, a bit risky, but IMPORTED is what should be used, and config suffix too

[jcar87]

This looks good to me with two caveats:

• Without this fix, a situation where a consumer project as "Debug" as the build type, and the dependencies where installed as "Release" - CMake gives you a warning (or an error dependency on policy). The warning is indicative of the mismatch and the potential problems. With this fix in the same situation, there's no longer a CMake warning, but compilation will fail. - this may make the user experience confusing.
  If the consumer project does not explicitly do mapping, the observed behaviour is the same with and without this PR.

• The CMAKE_MAP_IMPORTED_CONFIG_ in the consumers side accept, as value, a list, not just a single config. If we have a situation where a consumer runs conan install for multiple build types, and the CMake side has a configuration that can be satisfied by "any" of those - they could express something like set(CMAKE_MAP_IMPORTED_CONFIG_RELEASE Release RelWithDebInfo MinSizeRel Debug ""). I'd say this is very unusual, but as explained in this CMake issue, that would cause multiple generator expressions to be matched, likely resulting in libraries from different build times to be simultaneously linked...