Followup to #46391. That should be reviewed and merged first.'

Our existing OOP system works in the following manner:

1. change happens in VS.
2. VS waits 4-5 seconds to sync that change to OOP, with the presumption that the information will not be needed tehre soon, but that its' still good to generally be keeping OOP near up to date, so that when an OOP request does go in, there isn't that much to sync (effectively just the last 5 seconds of changes).
3. OOP will hear about the change, update it's solution snapshot, then kick off incremental analyzing
4. incremental analyzing will process high-pri stuff, and then back off another 1.5 seconds to start doing normal analysis.
5. results found by an incremental analyzer are sent to VS, where they are batched to be processed in the future.
6. 1 second later, the batch is worked on, real results are determined and VS is notified about this.

All in all, this leads to a situation where there can be a minimum of around 7.5 seconds between a text change, and a corresponding VS UI update. This is very noticeable and makes the product feel broken.

The above worked well because we didn't use to do things proactively in OOP. i.e. OOP was a place where requests were remoted in response to an explicit user request (i.e. user explicitly invokign FAR). At that point, we'd just need to sync a little data (fast), and then perform our op and return the results.

Now that we have proactive OOP subsystems running automatically in response to changes, the above isn't viable as it just takes far too long before the work even kicks off. I've changed the above to now be:

1. We start syncing to oop 500ms after a change. This ensures that a large flurry of changes still backs off, but that one there's a slight pause, that OOP knows about it and can go.
2. OOP syncs things over and kicks off incremental analyzer.
3. incremental analyzer still waits 1.5 seconds here. This is a standard wait time that we've found strikes a good balance between not doing too much work, or being distracting, while also getting to things in a timely manner when teh user makes a change tehy do care about.
4. results are then sent back to VS which just waits 250ms. Again, this is to at least be able to process a large flurry of messages in a single go, rather than processing each one sequentially with high overhead (esp. if a message has to go back to the UI thread).

Things brings our time delay for things like updating the winforms designer icon from 7+ seconds down to a much more reasonable 2.25 seconds. This does not feel immediate, but feels much more reasonable. Instead of taking so long that it feels like something is actually not working, things happen fast enough that you can move to your next task.