Fix color boxes not updating in some cases

[rchl]

As was noticed in #1839 (comment), it was incorrect to use _when_selection_remains_stable_async for the features that relied on view changes being reported first.

The _when_selection_remains_stable_async would cause the request to be skipped if the selection has changed since it was called. That means that changing the document and then quickly moving the cursor would result in color boxes not being requested/updated.

And on top of that, we might have also requested color boxes before the didChange notification has been triggered thus resulting in out of sync positioning of boxes.

Moved the logic to SessionBuffer where it can be called after the didChange notification and added checks if view is still alive and whether the document has remained the same on getting results from session.

We also shouldn't need any extra debouncing as didChange notifications are already debounced.

As a side effect, we'll request color boxes from all active sessions that support them rather then only the first one. This might be good or bad but if it's an issue, the user can disable relevant capability for one of the sessions.

[rwols]

Shouldn’t the PhantomSets go into the SessionView? I think the color regions are correctly stored in SessionBuffer but now clones won’t show the same phantoms right? Maybe they didn’t before as well.

[rchl]

Shouldn’t the PhantomSets go into the SessionView? I think the color regions are correctly stored in SessionBuffer but now clones won’t show the same phantoms right? Maybe they didn’t before as well.

How do we create clones again? Was it "Split View"? If so then it works as is. My best guess is that even though ST provides the api on the View, it internally ties phantoms to buffers and we are doing the right thing by creating them once instead of for each view clone.

[rwols]

In that case lgtm