Disregard semantic classification tokens from <template> portions of .gts files

[machty]

Closes #835

The solution here is to classify the spans/mappings for the generated TS representing code within <template> regions as shouldHightlight=false. This tells volar to NOT reverse-source-map the classification tokens generated by vanilla TS when parsing the generated TS representation of .gts files.

This has the desired effect of preserving the tokens for the outer TS regions of the .gts file while ignoring the tokens for the templates. It may be desirable at some point in the future to see see how the default classifications for the template portion can be "fixed", but I don't have a sense for how difficult this might be. I suspect the reason the default classifications looking "wrong" is due to some of the constructs used for getting the type-checking aspect of Glint working correctly, e.g. in some cases we might use something like __glintDSL.resolve('fooBar') to represent {{this.fooBar}} (this is not totally accurate, just an example); this might work really well for the purposes of generating useful diagnostics that can be source-mapped back to .gts, but when doing semantic classification, TS will classify this as a string argument to a function when really it's a simple property lookup on this.