Use Arcade-published SB SDK tarball

[mthalman]

We should consider following the same pattern that was introduced in dotnet/dotnet#1910 and apply that to the source-built SDK. This would mean that the VMR's prep script would reference the SDK tarball that was published via Arcade from a VMR build rather than the one published by the SB release pipeline.

Changes required to make this happen:

• Update VMR publishing to include SB SDK tarball (see Publish source build artifacts dotnet#1355)
• Update VMR prep script to reference the SDK tarball from the location being published to from the VMR (see Use SB artifacts RID dotnet#1910)
• Update the SB release pipeline to no longer publish the SDK tarball

[mthalman]

Unfortunately, I don't think we'll be able to finish this until the GA release. It requires that we have an Arcade-published SDK tarball. That's been merged in with dotnet/dotnet#2101. But it's not part of the RC 1 release. Since we can't have off-cycle rebootstraps now that we're in the RC phase, we won't have an Arcade-published SDK tarball from which to reference until RC 2 ships.

[mthalman]

This work can be done in the release/10.0.1xx branch once we've branched for RC 2. In other words, once RC 2 branches we can do a rebootstrap in release/10.0.1xx targeting an earlier RC 2 build. That build will have the associated SDK published for it. Then once RC 2 releases, the PR to update the VMR can be accepted as it will be a later build than the one referenced for this work. That will be allowed.

[mthalman]

We can't implement this for the same reasons that are described in #5332.