Should source-build-reference-packages use Microsoft.NET.Sdk.IL?

dotnet/runtime produces [Microsoft.NET.Sdk.IL](https://github.com/dotnet/runtime/tree/355ae18f40b4548f1baca724d97fdafea764bb3b/src/coreclr/src/.nuget/Microsoft.NET.Sdk.IL), which:
* Restores the right ilasm + ildasm packages, allowing for overrides
* Runs ilasm with some preset flags and extensibility (it appears, through `$(IlasmFlags)`)

The IL SDK seems to have been in a bit of ownership limbo, but it is used in at least one other non-dotnet/runtime repo, and there are some recent plans to be careful about breaking changes: https://github.com/dotnet/runtime/issues/1338#issuecomment-604431105.

source-build-reference-packages already knows how to call ilasm correctly, and has its own way to grab it. I don't *think* there are any improvements we'd get immediately from switching. I think there are mainly the ordinary nice results of sharing code: we simplify source-build-reference-packages, and the IL SDK *may* handle ilasm breaking changes (package name, flags, etc.), rather than us duplicating the changes after the fact. If source-build-reference-packages needs any more complex behavior, we could push it into the SDK so it can be reviewed/maintained by ilasm/ildasm experts.

The circular dependency is not a concern--this would be the same situation as the Arcade SDK. (And FWIW, source-build-ref-pkgs will get a deeper dependence on the Arcade SDK in 5.0.)

Thought of this while poking at https://github.com/dotnet/source-build/issues/1591 "Change source-build-reference-packages to follow the 5.0 plan as an ordinary repo". I don't think it necessarily makes sense to do in 5.0.

/cc @dseefeld @crummel @ViktorHofer