Use Dataflow and snapshots for dependencies node data processing

[drewnoakes]

The processing of data through the Dependencies node code has a few issues that I'd like to address in a batch, potentially in 16.8:

1. We have bugs around project configurations (e.g. multi-targeting bugs)
   • Dependency node does not handle configuration switches #3642
   • Dependencies node fails to handle custom target frameworks #2618
   • Remove all concepts of "target framework" and that configurations are driven from them #2525
   • Dependency node doesn't handle Multi-targeting with a multi portable frameworks  #2524
   • Remove concept of "short name" in TargetFramework #2795
   • TargetFramework fails to differentiate by NuGet profile name #2617
   • Multiple equivalent target framework short names cause exception #6203
   • Historically: NFE: Unknown active target framework #6204
   • Historically: Use friendly display name for target nodes in dependencies tree #6319
   • Historically: High CPU usage when IDE is idle. #2713
   • Historically: Visual Studio constantly consumes ~50 - 90% CPU after opening a large project #2388
2. Data providers currently notify of updates provide via .NET events
   • This is in contrast to most everywhere else where we use Dataflow
   • Makes it hard to implement features such as:
     • Add an API that lets consumers wait on dependency node to be up-to-date with a given project version #3426
3. Data providers are stateless, and publish deltas
   • This is in contrast to most everywhere else where we send snapshots
   • Makes it difficult to reconcile differences between evaluation and design-time build data
     • Idempotent Project Changes can leave Dependency Node Unresolved #2510
       • Seen a fair few dupes of this (Direct and transitive reference to project causes warning error on dependencies node #5335, Changing OutputType from Exe to WinExe marks SDK as unresolved #4550, possibly Renaming a project marks package references as unresolved #5356)
     • Don't show dependency warning icons while waiting for design-time build #5044
   • Makes it hard to implement features such as:
     • Support Solution Explorer search within framework reference assemblies #6139
     • Unused references/packages should be visually distinct #76
     • @ocallesp's work to show unresolved references in the tree
     • NuGet potentially showing showing upgradeable packages in the tree
   • A per-provider snapshot should make it easier to reduce memory wasted on long string identifiers
     • DependencyIDs create a lot of long, duplicate strings #5051
4. There are two ways to submit tree updates (public IProjectDependenciesSubTreeProvider and internal IDependencyCrossTargetSubscriber) where there should only be one
5. The concept of 'filters' should be removed
   • They attempt to work around the statelessness of dependency providers but distribute logic in multiple places, which makes design and debugging difficult
   • They require passing forward lots of state for later steps to use, which could be avoided if the providers were more self-contained and did that work themselves
   • Fixed in Remove concept of snapshot filters from dependency tree data handling #7992
6. Debugging Dependencies node issues is harder than it should be
   • If providers produced snapshots it'd be much easier to inspect their behaviour
   • Easier to know why we have a yellow triangle
     • Assembly references showing as unresolved despite compilation working #4885
7. By using Dataflow we could have fewer concepts and less code
   • Remove e.g. IDependencyCrossTargetSubscriber, AggregateCrossTargetProjectContext, AggregateCrossTargetProjectContextProvider
   • Use CPS's infrastructure e.g. UnwrapCollectionChainedProjectValueDataSource
8. The "Dependencies" tree does not populate with the first version of the visible tree. Its children appear later.

The work is mostly self-contained within this repo, however it will also require synchronising changes with the WebTools team for NPM dependencies.