Add new multithreaded APIs - #12625

Under MSBuild's multi-threaded mode (-mt), TaskRouter routes every task that
lacks [MSBuildMultiThreadableTask] to an out-of-proc sidecar TaskHost. In the
VMR runtime inner build this raised TaskHost invocations from 849 to 14,125 and
added ~98s of net task time, cancelling out most of the expected -mt savings.

Analysis
--------
Every concrete Arcade task (136 total) was checked against the rule set from
dotnet/msbuild src/TaskAnalyzer - the MSBuildTask0001/0002/0004 banned-API
tables plus static mutable state - using a Roslyn walker with transitive
call-chain analysis, so violations reached through shared helpers are caught.

MSBuildTask0003 (relative paths) is not treated as a blocker: MSBuild's own
Copy, Exec, Unzip, ZipDirectory and every ToolTask-derived tool task carry the
attribute. The bar applied here is no process-global state (env vars, cwd,
Path.GetFullPath/GetTempPath, Console.*, Process.Start) and no unsynchronized
static mutable state.

44 tasks came back clean and are annotated. The remaining 92 need code changes
and are tracked in dotnet/arcade#17378; most are blocked by a shared helper
(PackageIndex, LocateDotNet, the Helix/AzDO client stack, the publishing stack)
rather than by the task itself.

MSBuild package bump
--------------------
MSBuildMultiThreadableTaskAttribute was added in dotnet/msbuild#12625 and first
shipped in 18.3.x, so the 17.12.50 pin could not compile it. Bumped to 18.4.0,
which ships net472 and net10.0 libs matching Arcade's NetMinimum. This is
runtime-safe on older hosts: AssemblyTaskFactory only calls
TaskRouter.NeedsTaskHostInMultiThreadedMode when BuildParameters.MultiThreaded
is true, so a 17.x host never enumerates the attribute.

TargetFrameworkResolver race
----------------------------
TargetFrameworkResolver.CreateOrGet used an unsynchronized static readonly
Dictionary with TryGetValue/Add. Switched to ConcurrentDictionary.GetOrAdd,
which is both a correctness fix and what unblocks the two hottest tasks -
ChooseBestP2PTargetFrameworkTask (1740 invocations, +16.1s under -mt) and
ChooseBestTargetFrameworksTask (1195 invocations, +12.2s), together roughly 35%
of the measured TaskHost overhead.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>