While evaluating best practices related to CPS configuration use, a
question was raised as to what configuration mapping CMake uses to
choose the configuration of a target linked by another imported target
for which a non-standard configuration was chosen; namely, does CMake
use the `MAP_IMPORTED_CONFIG_<CONFIG>` for the configuration associated
with the most ancestral target / the project's build type, or for the
selected configuration of the direct consumer of the target?
It turns out the answer is "the former", and that this is actually the
more user-beneficial choice, as it allows users to craft configuration
maps that easily allow multi-axis configuration selection on correctly
crafter hierarchies, which are something CPS has "recommended" almost
since its inception (but CMake cannot presently generate).
This has three effects. First, it means that CPS suggesting such
hierarchies as a way to implement multiple configuration axes is not
actually as insane as it would be otherwise. Second, it means that
consumers can specify mappings for transitively included targets without
needing to know or care about what configurations of the intervening
targets exist. Third, it means that the current behavior is desirable,
and having something which verifies that behavior is useful. Thus, this
adds a test to do exactly that.
There are no actual behavior changes here; the test only verifies the
already existing behavior.
