Support nuget pack targets in static graph with isolation

Building a graph containing packable (which triggers the nuget pack targets to run) projects that are not terminal leaves triggers the isolation constraints.

The pack logic is run on the outer build nodes. The nuget pack targets use the MSBuild task to call into various nodes not predicted by the static graph, and thus fails isolation constraints:
- outer build pack computes its transitive closure and only MSBuild calls into closure nodes that are outer builds themselves (via `Pack -> GenerateNuspec -> _GetProjectReferenceVersions`).
- outer build pack calls into its inner builds nodes multiple times. Some of the calls match the inner build nodes predicted by static graph, but some do not, as they add extra global properties (via `Pack -> GenerateNuspec -> _WalkEachTargetPerFramework`).

We need to enhance the static graph declaration expressivity (probably the [ProjectReferenceTargets protocol](https://github.com/dotnet/msbuild/blob/master/documentation/specs/static-graph.md#inferring-which-targets-to-run-for-a-project-within-the-graph)) to allow the nuget team to express the funky calling patterns that nuget pack is doing, such that static graph can predict and create nodes that capture those calls.

Generalizing what pack is doing:
- a project can express that it depends on its closure. This is already implemented via [AddTransitiveProjectReferencesInStaticGraph](https://github.com/dotnet/msbuild/blob/master/documentation/specs/static-graph.md#constructing-the-project-graph)
- enhance this ability to also filter the closure by global properties. In nuget's particular case, filter the closure to only include outer builds (that is, filter by ignoring nodes that have the TargetFramework global property set).
- a project can express that it further decorates some of the nodes predicted by the graph with extra global properties. In nuget's particular case, this is the outer build calling into the the inner build nodes with additional global properties.