feat: support sublime text colors in color schemes

[rchl]

Patch https://github.com/microsoft/vscode-json-languageservice during building with support for some of the ST's colors.

Supports rgb(a)/hsl(a)/hwb formats. When using within a color(...) function, only basic forms are supported (color(..., alpha()).

Of course there is no support for colors referenced through var() since that would require knowledge of structure to fetch colors from one place and show them in another.

Some examples:

[predragnikolic]

Nice! Here are my first thoughts.

When I first saw the title of the PR, without looking at the code I assumed that you overridden the document color response with on_server_response_async and added the code for handling the new colors there.

---

Then I looked at the PR, did not expect to see the git patch :)
Not gonna say if that is good or bad, it feels hacky on first glance, and requires a script.

---

Other things that came to my mind is to expose Providers APIs to allow writing code like this:

import LSP

class SublimeTextColorProvider(LSP.DocumentColorProvider):
    name= 'Sublime Theme Color Provider'
    activation_events = {
        # 'selector': 'source.json',
        'on_uri': ['file://*.sublime-theme', 'file://*.sublime-color-scheme'],
    }
    def provide_document_color(self, view, params: LSP.types.DocumentColorParams) -> LSP.types.ColorInformation | None:
        return ...

In the future we might have LSP.DocumentColorProvider, LSP.HoverProvider, LSP.InlineValuesProvider, LSP.DiagnosticProvider.
That would allow more flexibility, but require more thoughts because it is a new approach.

[predragnikolic]

The benefit of doing it on the server side as you did, is because the server has already the correct ast. My solutions, would not give that level of preciseness that is required...

[rchl]

Ideally I would just submit the patch upstream but there is no doubt in my mind that such Sublime-specific logic won't be accepted. The syntax of those ST variants doesn't even match versions that are in the HTML specification.

So this approach seems to me like a second best. I'm applying my patch to the original code of vscode-json-languageservice and then building a new version of the package like would be done normally. The patch only attempts to parse colors in places that specify type: color in the schema in case that wasn't obvious.

I have to say that I've come across issues with yarn rejecting my package override (as I was iterating on the patch). It has some storage where it keeps SHAs of the packages and rejects them if already seen package has different SHA. This could potentially become an issue if we have to update the patch while the version of vscode-json-languageservice stays the same.