[ArPow] intermediate nupkg restore tooling should detect and fail if multiple <SourceBuild .../> elements exist for one upstream

[dagood]

If we have dependencies defined like this:

    <Dependency Name="Microsoft.DotNet.Arcade.Sdk" Version="6.0.0-beta.21105.5">
      <SourceBuild RepoName="arcade" ManagedOnly="true" />
    </Dependency>
    <Dependency Name="Microsoft.DotNet.ApiCompat" Version="6.0.0-beta.21105.5">
      <SourceBuild RepoName="arcade" ManagedOnly="true" />
    </Dependency>

There's a potential that the versions will diverge if one of the package names change, one of them is manually updated. And actually divergence can be intentional, for targeting packs:

    <Dependency Name="Microsoft.NETCore.App.Ref" Version="5.0.0" CoherentParentDependency="Microsoft.NET.Sdk">
      <SourceBuild RepoName="runtime" ManagedOnly="false" />
    </Dependency>
    <Dependency Name="Microsoft.NETCore.App.Runtime.win-x64" Version="5.0.2" CoherentParentDependency="Microsoft.NET.Sdk">
      <SourceBuild RepoName="runtime" ManagedOnly="false" />
    </Dependency>

Once they diverge, I think that the tooling will bring down two versions of the intermediate nupkg, which doesn't represent what source-build can actually do in a tarball.

Picking a single dependency node is how we decide what the coherent graph of repos should be.

I think the tooling should detect when a repo is set up this way, and fail pre-emptively.

---

For #2034, we'll probably need to restore multiple intermediate nupkgs from a single upstream, but all of them should come from a single dependency node.

[dagood]

Triage: this is just a safeguard, but when this scenario happens down the road, we don't know how it will show up--if it's easy to diagnose a build break or if it will silently break the SDK. This seems like it won't be a problem in the initial work but it's worth tracking.