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 89.79%. Comparing base (5d8a7fe) to head (0af031d).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4232      +/-   ##
==========================================
- Coverage   89.87%   89.79%   -0.09%     
==========================================
  Files          37       37              
  Lines        4780     4780              
==========================================
- Hits         4296     4292       -4     
- Misses        484      488       +4     

[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

[puremourning]

Reviewed 1 of 1 files at r1, 1 of 1 files at r2, all commit messages.
Reviewable status: 1 of 2 LGTMs obtained (waiting on @bstaletic)

---

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

Previously, bstaletic (Boris Staletic) wrote…

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

I think I like Type for this. thanks.

[puremourning]

@Mergifyio rebase

[mergify]

rebase

✅ Branch has been successfully rebased

[mergify]

Thanks for sending a PR!