Add new semantic token types

[bstaletic]

PR Prelude

Thank you for working on YCM! :)

Please complete these steps and check these boxes (by putting an x inside
the brackets) before filing your PR:

• I have read and understood YCM's CONTRIBUTING document.
• I have read and understood YCM's CODE_OF_CONDUCT document.
• I have included tests for the changes in my PR. If not, I have included a
  rationale for why I haven't.
• I understand my PR may be closed if it becomes obvious I didn't
  actually perform all of these steps.

Why this change is necessary and useful

The decorator type was introduced in LSP 1.17.
The concept type is used by clangd.

Reported by @amosnier on gitter.
The mapped value is just the first thing that came to my mind. Feel free to suggest bette alternatives.

[Please explain in detail why the changes in this PR are needed.]

---

This change is 

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 78.22%. Comparing base (4556062) to head (f0a9213).

Additional details and impacted files

@@             Coverage Diff             @@
##           master    #4232       +/-   ##
===========================================
- Coverage   89.67%   78.22%   -11.45%     
===========================================
  Files          34       29        -5     
  Lines        4445     2760     -1685     
===========================================
- Hits         3986     2159     -1827     
- Misses        459      601      +142     

[puremourning]

Reviewable status: 0 of 2 LGTMs obtained (waiting on @bstaletic)

---

python/ycm/semantic_highlighting.py line 53 at r1 (raw file):

  'regexp': 'String',
  'operator': 'Operator',
  'decorator': 'Comment',

did a quick scan of the existing vim runtime files for decorator and see a little bit of inconsistency, but nothing like Comment; more decorators are highlighted like macros:

313:hi def link pythonDecorator		Define
314:hi def link pythonDecoratorName		Function

2091:hi def link typescriptDecorator             Special

Taking some liberty, I checked annotation too (as decorator/annotation are similar concepts), where PreProc is common:

385:hi def link dAnnotation          PreProc
208:hi def link scalaAnnotation PreProc
201:hi def link scalaParameterAnnotation Function
202:hi def link scalaParamAnnotationValue Keyword
203:hi def link scalaCommentAnnotation Function
348:hi def link javaAnnotation		PreProc

So I suggest following something like that. Maybe PreProc, maybe Special?

---

python/ycm/semantic_highlighting.py line 58 at r1 (raw file):

  # These are not part of the spec, but are used by clangd
  'bracket': 'Normal',
  'concept': 'Normal',

concept is a sort-of type right ? how does this look in practice ?

I know users can override HL groups but I feel like we should make it look good in the general case?

[bstaletic]

Reviewable status: 0 of 2 LGTMs obtained (waiting on @puremourning)

---

python/ycm/semantic_highlighting.py line 53 at r1 (raw file):

Previously, puremourning (Ben Jackson) wrote…

did a quick scan of the existing vim runtime files for decorator and see a little bit of inconsistency, but nothing like Comment; more decorators are highlighted like macros:

313:hi def link pythonDecorator		Define
314:hi def link pythonDecoratorName		Function

2091:hi def link typescriptDecorator             Special

Taking some liberty, I checked annotation too (as decorator/annotation are similar concepts), where PreProc is common:

385:hi def link dAnnotation          PreProc
208:hi def link scalaAnnotation PreProc
201:hi def link scalaParameterAnnotation Function
202:hi def link scalaParamAnnotationValue Keyword
203:hi def link scalaCommentAnnotation Function
348:hi def link javaAnnotation		PreProc

So I suggest following something like that. Maybe PreProc, maybe Special?

Went with Special, but could not get pyright to work, so could not test.

---

python/ycm/semantic_highlighting.py line 58 at r1 (raw file):

Previously, puremourning (Ben Jackson) wrote…

concept is a sort-of type right ? how does this look in practice ?

I know users can override HL groups but I feel like we should make it look good in the general case?

Tested with Type. Here's asciinema:
https://asciinema.org/a/4CdIJRP3ktEbrVlrpd8nmP35z