Fix diagnostic regions being hidden by semantic regions

[rchl]

This attempts to fix the issue where semantic regions are being added after diagnostic regions, causing the latter to become invisible.

As explained by @jwortmann this is because we don't initialize all combinations of semantic token region keys in SessionView._initialize_region_keys. We could attempt to do that but I figured we could just create a pool of region keys lsp_semantic_<number> where the number monotonically increases each time new region is seen. This way we can just initialize regions within certain range (I've picked 0-100 in this PR) and ensure that all semantic regions are drawn in specific order relative to other types of regions. At least as long as the server doesn't use more than 100 combinations of tokens.

This approach would not work properly if using more than one server that provides semantic highlighting for the same file but that had issues also previously and it's not a sensible use case anyway.

Fixes #1934

[jwortmann]

This is a good and simple idea, which I haven't thought of before.

Small nitpicks:

• looks like the first key from _get_region_key_for_scope() will be 1, so you can initialize the regions keys with range(1, 100) (or alternatively set self._last_semantic_region_key = -1 in __init__)
• the following comment should be outdated now and can be removed: # Note that the region keys for these scopes are not initialized in SessionView._initialize_region_keys.

As a sidenote, I remember reading somewhere in a GitHub issue or in the forum, that another package developer experienced ST becoming unresponsive and/or growing memory after some time, and iirc their plugin continuously generated new region keys with a timestamp on each mouse click or so for text highlighting. And there was an answer from one of the ST devs, that plugins are expected to only use a reasonable amount of separate keys for add_regions. That was basically why I didn't want to initialize all possible combinations of token types and modifiers (would be at least 22 * 10 = 220 only for the standard tokens, but potentially a lot more with custom tokens from the server). I haven't tested it, but I guess you have and I assume that the 100 keys don't have any performance impact. So this should be fine, just some sidenote to keep in mind.

And yes, the whole semantic highlighting implementation isn't designed for tokens from multiple sessions/servers at the same time for a file.

[rchl]

Thanks for the comments.

And there was an answer from one of the ST devs, that plugins are expected to only use a reasonable amount of separate keys for add_regions.

I didn't do any scientific testing but I've changed range(1, 100) to range(1, 10000) and didn't notice any significant difference in memory usage or performance (when scrolling). And it's now 100 regions for semantic regions while it was 48 before so it's not that big difference I guess.

[rchl]

Will merge later today if there are no more comments.