Add --rid top level option

[am11]

Closes dotnet/source-build#4413

cc @tmds, @ViktorHofer

[tmds]

Other than my comment about preferring --rid over --target-rid for the argument name, lgtm.

[am11]

It would be nice to reduce the disparity in terminologies because this situation is confusing and not very self-explanatory:

(source build)
--rid -> TargetRid
                  \
                --outputrid -> OutputRid -> CLI_CMAKE_PKG_RID
                  /
--outputrid -> __DistroRid
(regular build)

[am11]

All we really need is:

• identifier to restore the packages during the build (host platform).
  • this is automatically deduced during the build and cannot be overridden.
• identifier to build shipping packages for (target platform).
  • this is automatically deduced but it can be overridden from CLI.

[tmds]

It would be nice to reduce the disparity in terminologies because this situation is confusing and not very self-explanatory

• TargetRid was decided on a name at some point, and I think OutputRid still has to be refactored to use that name.
• __DistroRid is used to get a name from init-distro-rid.sh into the MSBuild side and determine a default TargetRid. I think we can keep the name as is, as it has a limited scope and the __ prefix suggest it is "private".

When we're adding top-level arguments to the vmr build script, I think we should name things so they are most clear to the package mantainers. They are supposed to figure out what to use without having to look at the implementation.

[am11]

Changed to --rid. Another prospect is that we align it to dotnet build (which I personally don't find better than rid):

$ dotnet build --help | grep IDENT  
  -r, --runtime <RUNTIME_IDENTIFIER>   The target runtime to build for.

[ViktorHofer]

I'm fine with calling it --rid but please also add the option to specify --target-rid and document it because that's the name of the underlying property in msbuild. We shouldn't allow the -r short form because that's already reserved for restore. The VMR script doesn't yet have that option but we will eventually add it.

[am11]

Windows aspnetcore failure is unrelated (failing on other PRs too).

[tmds]

@am11, thank you for picking this up!