Add semantic tokenization tests

[OceanOak]

This PR fixes semantic tokenization, and adds tests for it

[OceanOak]

Todos and things to consider for a follow-up PR:

• Maybe in List <'a>, DB<'a>, and Dict<'a>, the <'a> should be tokenized as a typeParam instead of tokenizing <, typeName, > separately.

• in Dict maybe key should be tokenized as a property instead of a string?

• in EPipeEnum, all of this is Stdlib.Result.Result. is tokenized as a TypeName instead of ModuleName.ModuleName.TypeName. Same for EPipeFnCall and MPEnum

• maybe true and false shouldn't be tokenized as Keyword

  Reason:
  lets take this example: if true then true else false
  the result of the semantic tokenization will be: Keyword Keyword Keyword Keyword Keyword Keyword
  and it will be highlighted in the same color, which doesn't look right
  (Maybe no one will write such code; it's just an example of an extreme case where everything would be
  tokenized as a keyword.)

Notes in case we decide to capture all symbols some day:

currently, we are not tokenizing the following:

• the .s in fully qualified type name, function name, and constant name
• the {} and ; in Type Declaration Record
• the ; in List
• both the = and ; in Dict
• the () in PipeInfix and PipeLambda

[StachuDotNet]

Those are great comments - I added a link in #5259 to that comment so we don't lose track.
Quick thoughts:

• typeParam point: yeah, probably good to reuse some functionality there
• Dict key thing: yeah I'd say so
• "maybe true and false shouldn't be tokenized as Keyword" - agreed. Just took a look and seems F# tokenizes true and false as other or constant (depending on which tokenization system). adding a new token type for constant might work well for us here. no 'default' available tokens fit super well, besides keyword, and the problem you outline is real

[StachuDotNet]

Great work here - shame the auto-formatter does at it does, but those tests will look tidier soon. We'll be thankful for these tests.