Remove reference packages from source build artifacts

[MichaelSimons]

Once #1690 is fixed, there will no longer be a need to include the reference packages in the source build artifacts. Additionally the special logic to initialize the prereqs/packages/references as part of initializing source build can be removed.

[ViktorHofer]

This target and the corresponding props should also be removed: https://github.com/dotnet/dotnet/blob/e77087921640d19846d5b0749c219674df917745/repo-projects/source-build-reference-packages.proj#L23-L33 & https://github.com/dotnet/dotnet/blob/e77087921640d19846d5b0749c219674df917745/repo-projects/source-build-reference-packages.proj#L14-L15

[MichaelSimons]

[Triage] It turns out the reference packages are required during source build initialization. For example they are required to build the msbuild tasks. @ViktorHofer has an idea on how we could eliminate the dependency by using n-1 artifacts. Assigning to him as he was going to create a POC of this. If this doesn't prove out, we should just close this. The benefits are relatively low given how small the source build reference packages are these days (~25 MB).

this comment](#4930 (comment)) was address already by dotnet/sdk#47291

[MichaelSimons]

@ViktorHofer, How do you feel about closing this? The motivation behind this was the belief that the reference packages were only needed because of the way SBRP was defined with package downloads. The size of the SBRPs in the archive are currently 33.8 MB so from that perspective additional work to remove these doesn't feel justified.

There is potential value in providing the ability to build the VMR's msbuild tasks against live references from the previous SB artifacts but the motivation for that work is different. If you feel that should still be pursued, I think a separate issue should be opened that accurately captures the motivation.

[ViktorHofer]

Agreed, let's close this one. We depend on two SBRP packages in the VMR orchestrator: Microsoft.Build.NoTargets and Microsoft.Build.Traversal. Those are strong dependencies and we would need to special case them which is probably not worth it.

I will file a new issue to track adding support for referencing previously SB artifacts in the VMR orchestrator: #4976

[NikolaMilosavljevic]

Reopening, as this will be unblocked with #5065