Error squiggles shown too aggressively in VS2015 Update 1

[Pilchie]

Based on user feedback that it took too long for error squiggles to appear, we took a change for Update 1 to shorten the delay.

That in turn has sparked several VS Feedback reports (e.g. 517898) that the squiggles are too noisy and in the way. We should think about tuning this further. Some thoughts we had included:

1. Restore the longer delay, but provide a less intrusive way of indicating that code fixes are available on the same short delay (maybe the old smart tag tickers? Maybe classifying unbound identifers explicitly?)
2. Restore the longer delay, but provide some way to force errors to appear (for example VB in VS2013 used "line commit" like saving, or moving of the line to do this).
3. Split the difference in the times between what we had in VS2015 RTM and what we have now in U1.

@jasonmalinowski @DustinCampbell @kuhlenh - this is the conversation we were having earlier. Also tagging @CyrusNajmabadi @heejaechang @srivatsn as people who've generally put a lot of thought into this space.

Other suggestions?

[jasonmalinowski]

If our original goal by shortening the delay was to make squiggles go away sooner after fixing them, we could also make the show/hide delays different -- squiggles take a while to appear, but disappear more quickly.

[Pilchie]

As we discussed this morning, I think people like @ljw1004 wanted a way to force errors to appear quickly in order to be able to invoke a fix, so we probably couldn't do your suggestion apart from also doing something like item 1 above.

[heejaechang]

we have many delays affecting squiggles and LB. so we probably need to figure out the scenario first.

...

sequence of events and delays are (all pipelines below are async - either await calls, or async events), so there can be implicit delay based on current state of vs process - most likely very quick but I saw cases where it takes while (several milliseconds) to continue)

1. user types (workspace changed)
2. solution crawler picks it up and put in the work item queues (3 different queues with different delays)
3. semantic change processor picks up the work item and propagate it to affected items (dependent projects and etc ) (other delay)
4. as result of /3/, semantic change processor creates new work item and put them in the queue (same queue as /2/)
5. diagnostic engine pick up the work item and process and raise events
6. listeners of diagnostic events start their own process.

...
syntactic squiggle. I believe this is synchronous. so this probably doesn't affected by diagnostics delay.
semantic squiggle. it was it own delay to process tags once it got from the engine. (other delay)
...
LB. after diagnostic engine events, we let editor know about the change and they call us back - can't remember whether they had their own delay or not. but for LB, we support synchronous path with ctrl+.
...
error list. once we got diagnostic events, error list has its own delay (other delay)

...

[heejaechang]

I forgot to mention one thing. I already made a change where showing LB due to typing or caret position change doesn't require diagnostic events. meaning we can slow down high priority queue delay even more (I already made 200ms to 500ms I think when I made the change above) without affecting LB.

behavior change will be squiggle and error list delay will be longer than now without affecting LB on active file on typing or caret position changes.

LB will be also affected for non-active file semantic changes.

[heejaechang]

addressed by #8102