Re-add typeassert highlighting

[jakobnissen]

See issue #317.

I'm not sure how to test it rigorously, but it appears to work. It doesn't properly handle e.g. x::Vector{Int} as the {Int} part is not colored as part of the type. I guess the way to handle that would be to do a pre-processing pass over the tokens and collapse {Int, UInt} into a single "type token" as it was using Tokenizer.jl

[codecov-commenter]

Codecov Report

Patch coverage: 100.00% and project coverage change: -0.07 ⚠️

Comparison is base (243ef61) 56.59% compared to head (1c6ed6e) 56.52%.

📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #322      +/-   ##
==========================================
- Coverage   56.59%   56.52%   -0.07%     
==========================================
  Files          15       15              
  Lines        1115     1118       +3     
==========================================
+ Hits          631      632       +1     
- Misses        484      486       +2     

Impacted Files	Coverage Δ
src/passes/SyntaxHighlighter.jl	67.46% <100.00%> (-1.29%)	⬇️

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[c42f]

I guess the way to handle that would be to do a pre-processing pass over the tokens and collapse {Int, UInt} into a single "type token" as it was using Tokenizer.jl

The "right way" to do this, IMO, would be to use the full parse tree from JuliaSyntax: we're not limited to a mere sequence of tokens anymore :-)

Then it's super simple: everything under the second child of K"::" nodes is highlighted as a type.

[c42f]

Presumably we'd want to use the green tree you'd get from parseall(GreenNode, code) because we want to highlight syntax trivia like comments. (Note, the green tree doesn't have the most convenient interface given it stores spans and not source text. Actually this use case might be an interesting exercise in coming up with a more convenient iterator API (maybe?) on top of the green tree.)