Pass CLR_CROSS_COMPONENTS_BUILD as a separate -cmakeargs

[pcshrosbree]

Fixes #135468

The host cross-components build and the linuxdac and alpinedac builds in eng/Subsets.props appended the flag to the user's CMake arguments:

CMakeArgs=$(CMakeArgs) -DCLR_CROSS_COMPONENTS_BUILD=1

runtime.proj turns each CMakeArgs item into one -cmakeargs "%(Identity)", so the flag shares a value with the last user argument. build-runtime.cmd keeps a quoted -cmakeargs value as a single CMake argument: on Windows, -cmakeargs -DCLR_PROBE_NOOP=1 reached CMake as one definition of CLR_PROBE_NOOP with the value 1 -DCLR_CROSS_COMPONENTS_BUILD=1, and CLR_CROSS_COMPONENTS_BUILD was never defined. On Linux, the shared build_native function in eng/native/build-commons.sh reparses the accumulated arguments with eval, so the flag still arrived as a separate argument.

This sets ClrCrossComponentsBuild=true on those three projects instead, and runtime.proj passes -cmakeargs "-DCLR_CROSS_COMPONENTS_BUILD=1" as its own entry, the way it already passes FEATURE_INTERPRETER and the other internal defines. The user's CMakeArgs still reaches the sub-builds unchanged, as a global property. ClrCrossComponentsBuild joins CMakeArgs in NativeBuildPartitionPropertiesToRemove, so runtime-prereqs.proj and cdac-build-tool are not built again because of it.

The new entry is listed before the user's CMakeArgs. Both build-runtime.cmd and eng/native/build-commons.sh prepend each -cmakeargs, so it ends up after all of the user's arguments on the CMake command line, and a user -DCLR_CROSS_COMPONENTS_BUILD=0 does not override it. For -cmakeargs given to build.sh or build.cmd, which arrive as a single CMakeArgs item, this is the order Linux already had.

Splitting CMakeArgs on spaces in runtime.proj would also make these builds pass, but it would break a CMake argument that contains a space.

Validation

There is no test harness for these MSBuild files, so this was checked by building from fresh obj dirs at 716a871 and reading the build-runtime command lines and each sub-build's CMakeCache.txt. CLR_PROBE_NOOP and CLR_PROBE_TWO are placeholder names.

Windows x64 host:

command	before	after
build.cmd clr.runtime -a arm64 -c Debug -cmakeargs -DCLR_PROBE_NOOP=1	fails: x64\debug\di\floatconversion.asm(2748) : error A2008:syntax error : GBLA; x64\CMakeCache.txt has CLR_PROBE_NOOP:UNINITIALIZED=1 -DCLR_CROSS_COMPONENTS_BUILD=1	builds; x64\CMakeCache.txt has CLR_CROSS_COMPONENTS_BUILD=1 and CLR_PROBE_NOOP=1 as separate entries
build.cmd clr.runtime -a arm64 -c Debug	—	builds; CLR_CROSS_COMPONENTS_BUILD=1 in x64\CMakeCache.txt
build.cmd linuxdac -a x64 -c Debug -cmakeargs -DCLR_PROBE_NOOP=1	fails at CMake configure (System.Net.Security.Native/extra_libs.cmake:30), with the same fused cache entry	builds the linux-x64 mscordaccore and mscordbi

Linux x64, ./build.sh clr.crossarchtools -a arm64 -c Debug (builds only the x64-hosted cross components):

-cmakeargs	before	after
-DCLR_PROBE_NOOP=1 -cmakeargs -DCLR_PROBE_TWO=2	builds; CLR_CROSS_COMPONENTS_BUILD=1, CLR_PROBE_NOOP=1, CLR_PROBE_TWO=2	builds; same cache entries
(none)	—	builds; CLR_CROSS_COMPONENTS_BUILD=1
-DCLR_CROSS_COMPONENTS_BUILD=0	CLR_CROSS_COMPONENTS_BUILD=1	CLR_CROSS_COMPONENTS_BUILD=1

alpinedac takes the same path as linuxdac and was not built separately.

[azure-pipelines]

Azure Pipelines:
Successfully started running 3 pipeline(s).
13 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.