Build Arcade submodule

[dagood]

Add https://github.com/dotnet/arcade to the build. This is the new toolset for 3.0 we need to build from source. Repos will use it as the build toolset, and we'll use its Darc tool for various dependency operations.

There are plans to convert 2.1/2.2 to use Darc as well, so I think we should work on this in release/2.1.

[dagood]

With what's in Arcade master now, the build generates this baseline. A lot of new things, and ASP.NET:
https://gist.github.com/dagood/5ea2b5ac700e42ad5d06b3760df2e30e

Doing some more excluding gets rid of a bunch:
https://gist.github.com/dagood/6b5967e89138317c29cac9841ec70710

Updated dotnet/arcade-services#2578 with interesting dependencies on the Darc projects. (Web-related for the most part.)

[dagood]

This seems to be working. release/2.1...dagood:wip-arcade-1 builds arcade and forces arcade-minimalci-sample to use the built SDK. Works pretty much exactly like RepoToolset/roslyn-tools. I generalized the SDK override resolver a bit to fit both SDKs, since we'll probably need to support both at least at first.

---

Now I'm thinking deeper about how to bring this into source-build while nothing in source-build actually uses Arcade SDK or Darc yet. (CoreFX will be our first in master, but release/2.1 also matters here.) Adding arcade (and arcade-minimalci-sample?) and letting it blindly build doesn't accomplish much: the submodule won't ever auto-update, and it puts on extra CI time. All we would be doing is making sure source-build infra changes don't break it--and even that detects a problem, it just means more maintenance of something we don't use.

I think this can tie into #379 "add dependency tripwire CI in each repo". We can put a new CI leg into arcade and source-build that runs source-build infra with arcade-minimalci-sample as the RootRepo. That way, when either repo makes a change that breaks the other, PR validation will catch it. Issues:

1. The tripwire build needs some combo of source-build and arcade commit hash to try to build together.
   • Always using latest would be straightforward, but unstable.
   • Keeping a commit hash checked in of the opposite repo (source-build uses the submodule commit hash, arcade would need some checked in source-build hash) then auto-updating those with PRs would be stable, but a potential maintenance task. If we can leverage Maestro++ to auto-merge the cross-updates, that would make it more ok.
2. Handling the prebuilt baseline is interesting. People need to be able to fix baselines by making a change in their Arcade PR to unblock the PR's CI.
   • I think this can be dealt with separately--we don't need to address this part of tripwire CI in the first attempt. "Does the repo still source-build" is better than nothing. 🙂

[dagood]

Current plan is to add Arcade to the build in master once master has an Arcade-using corefx commit. Once Darc becomes useful in release/2.1/release/2.2, we'll port the Arcade project back there to source-build it.

[dagood]

Completed in #916, we build Arcade and use it to build CoreFX.