Support a non script based entrypoint

- [ ] This issue is blocking
- [ ] This issue is causing unreasonable pain

Following up on https://github.com/dotnet/aspnetcore/pull/21017#issuecomment-621915214.

### Current state

Currently a repository build runs through these stages: build.cmd|sh --> eng/common/build.cmd|sh -> Arcade's Build.proj -> `Tools.proj`, `ProjectToBuild` items, `Sign.proj`, `Publish.proj`.

To get into more details, Arcade's Build.proj is current responsible for
- Upfront restore: Invoking the restore target on `Tools.proj` and on the `ProjectToBuild` items.
- Build the ProjectToBuild items (either a Solution File or msbuild project files)
- Sign
- Publish

With the current design, Arcade's Build.proj file invokes the `Restore` and `Build` target on every passed in project which has multiple caveats:

1. For every `ProjectToBuild` restore, NuGet is invoked. As a side note, in an internal thread it was discussed that the more often NuGet is invoked, the more likely the cross-org authentication plugin fails.
2. Using the newly added [NuGet static graph restore feature](https://github.com/NuGet/Home/issues/8791) works best (and fastest) with a single restore entry point.
3. Declaring dependencies between passed in `ProjectToBuild` items is difficult as you can either define `BuildInParallel` on all of them or on none.
4. `dotnet` CLI verbs like `dotnet build` and `dotnet restore` don't work on the repo root level.

### dotnet/runtime

In dotnet/runtime we recently removed passing all our `ProjectToBuild` items to Arcade and instead added a root repo Build.proj entrypoint file which uses [Microsoft.Build.Traversal](https://github.com/microsoft/MSBuildSdks/tree/master/src/Traversal) which is then invoked by Arcade's Build.proj file.

- https://github.com/dotnet/runtime/blob/master/Build.proj#L1-L12
- https://github.com/dotnet/runtime/blob/master/eng/Build.props

We additionally allow filtering on the Build.proj's ProjectReferences based on the `/p:Subset` property.

In addition to the Build.proj entry point file, we have repo local SDK acquisition scripts in the repository root which bootstrap the dotnet SDK (via the Arcade scripts) and invoke it.

https://github.com/dotnet/runtime/blob/master/dotnet.cmd
https://github.com/dotnet/runtime/blob/master/dotnet.sh

That combination allows us to run `dotnet restore`, `dotnet build` and `dotnet test` from the repository root. The caveat here is that Arcade's `Tools.proj`, `Sign.proj` and `Publish.proj` files aren't sequenced in if the repository's Build.proj file is invoked directly.

### Proposal

My ask is that we support an entrypoint in Arcade which avoids Arcade's eng/common/build.cmd/sh and Build.proj files completely. This could be achieved via
- a props/targets file import or
- an auto detection feature in the Arcade SDK to add props/targets/ProjectReferences to the entry point project.
- possible 99+ other solutions 😀

cc @markwilkie @tmat @dougbu @jeffkl @danmosemsft @ericstj

# Recently Triaged Issues

All issues in this section should be triaged by the v-team into one of their business objectives or features.