Various textmate scope improvements

[dnut]

Traits and enums are only assigned the entity.name.type.trait and entity.name.type.enum scopes in their declaration. This isn't very useful since it doesn't actually apply to the usage of the types, where being able to identify by color would be much more useful. In usage, they instead get entity.name.type.other. So it's disorienting because you might think that traits are supposed to be green, but it's yellow when used so you think it's a struct instead. The declaration and usage need to be consistent. I've just made them all the same color in my theme to avoid confusion from inconsistency.

Some new scopes would be nice as well:	Description	Current scope	Proposed scope	Comment
Enum variants	entity.name.type	entity.name.type.enum-variant	For java this is scoped under "constant.other.enum" but I don't think "constant" is right for rust enum variants. I said enum-variant instead of enum.variant because, if unspecified, I would actually default these to the regular struct color before I would color them like the enum. Like the enum name, I would expect this to have the scope in declaration and usage.
Function parameters	variable.other	variable.parameter	VS Code actually gets this right already for java, but not rust.
Type Paramaters	entity.name.type	entity.name.type.parameter	Sometimes it's necessary to have descriptive type parameter names when you have several type parameters. In those cases, it can get confusing distinguishing them from actual structs. It would be great to be able to distinguish them by color.
Struct fields	variable.other	variable.field	Like enums and traits, I would expect this to have the scope in declaration and usage. For java, fields do not have a special scope either--those are called "variable.other.definition". So the issue does apply more broadly.
Constants	variable.other	constant	If you're following the coding conventions, this will be capitalized and get the constant.other.caps scope. But syntax highlighting should represent the actual syntax, not whether the name is capitalized. I can see the case already. Rather than every type of variable name having the same pair of styles based on case, each type of variable name should have its own single style.
Static variables	variable.other	variable.static	Same comment for const applies here. It's valuable to have an obvious way to identify by color that something is global rather than local, especially for static variables since they may be mutable.

[Wilfred]

Agreed, I'm open to PRs if you'd like to work on this :)