I recently noticed an issue that has likely been present for a long while. Essentially, metadata
references are never removed from the workspace. The reason for this is because Roslyn's MetadataReference
class does not implement value equality -- it just inherits the default `Equals()`/`GetHashCode()`
implementations from `System.Object`. However, the algorithm for adding and removing metadata references
assumes value equality. This is easily fixed by adding our own `IEqualityComparer<MetadataReference>`
that first checks to ensure that `MetadataReferences` are `PortableExecutableMetadataReferences` and then
uses their file paths for equality.

This change unifies file and directory watching, separates watching and notification concerns in the API,
and fixes the following issues:

1. Paths are treated case-insensitively as they are in the rest of OmniSharp.
2. Access to the internal dictionary of callbacks is synchronized.

… project

This is a pretty substantial change that reworks the core logic of the MSBuild project
system to enable an important scenario: updating a project when several files change in quick
succession.

In order to fix an issue with OmniSharp not reloading and updating a project in response to
a 'dotnet restore', we must watch four files that might be touched during a restore:

* project.asset.json
* <project-file>.nuget.cache
* <project-file>.nuget.g.props
* <project-file>.nuget.g.targets

To ensure that we don't reload and update a project multiple times in response to multiple file
changes, this PR introduces a simple queue and processing loop using a TPL DataFlow BufferBlock.

Previously, we tracked whether a project update *could* invoke an automatic
'dotnet restore' and this PR adds that back. Essentially, we allow auto restore
in all cases that a project is updated *except* when the update comes via a restore.