…Tagging

Cancel all current work with highlight refs when changes come in

In 63a1ad6 we made some performance
optimizations where we would try to reuse compilations better. The core
idea was if a change to a file happens, we have to update the
compilation that doesn't contain source generated files so we can
re-run generators; if the generated output was the same then we should
also do the same updates to the compilation that _has_ source generators
so we can better use compiler caches.

The one case that wasn't handled well was if the compilation with
and without generated output was actually the same: if a generator was
added that isn't producing documents, then those compilations can
be the same instance, but we were applying the transformations
twice as if they were different. This fired an assert elsewhere in
the CompilationTracker that when we're storing compilations away at
the very end we shouldn't have two separate but semantically identical
compilations if there are no actual generated files anywhere.

The fix taken here is to adjust our logic where we update compilations
for changes to regular files: there we were updating both compilations
at once. If the compilations are identical, we just null out the
"withGenerators" since we won't need to update that as well. That way
we're only updating one copy, which will be the one passed to generators
again. And if no generated output is still produced, that'll be the
single compilation again stored in the FinalState.

Optimize the case when we have a generator not producing output

Move to Ubuntu 18.04 queue

…ties yet (#53000)

…actory-implementation

Do not show UI if no managed projects are loaded

Make CodeAction.CustomTags internal