Feature/add enum support

[SludgeGirl]

Detailed description

This adds in parsing and syntax highlighting for enums

I've been testing against the following definition:

[[FlagsEnum]]
enum ConsoleOptions
{
	debug = 100,
	testing = 200,
	test1
}

Your checklist for this pull request

• I've read the Code of Conduct
• I've read the guidelines for contributing to this repository
• It builds and lints cleanly
• I've tested it to the best of my ability
• My commit messages provide a useful short description of what the commits do
• I've made sure that my commits are signed/verified

Closing issues

[dragonmux]

Thank you for the contribution! It's looking great and we're really happy with the direction you've taken this is. There are some stylistic items the review found and a couple of queries on logic/symbol handling, but once sorted, we're happy to merge this.

[dragonmux]

This should probably check && token.typeIsOneOf(TokenType.enumDef)

[SludgeGirl]

So the only token that's considered the enum type is the initial enum keyword, we also can't really force every token inside the enum to be of the enum type as when we parse the value assignments to the enum members they need to have their own typing, seperate to the enum.

Since the isEnum config key is set only once we've read the enum keyword and continue to parse the braces we thought this would be fine as no other routes could lead to this being reached and parsing anything else incorrectly, let us know if you have any thoughts on this one

[dragonmux]

It comes down to: Do we want to only allow enums to contain enumeration values, or do we want to allow them to contain conditional logic, visibility statements, functions, operator overloads, etc?

One of the biggest problems C++ has always had with its enumerations (after fixing the scope problem) is there's no way to directly attach functionality to the type such as helpers to string-ify the enumeration values, and operators to help build complex values from enumerated values. If you agree that can make sense here, and given this current setup does allow visibility statements already, then we think checking for TokenType.enumDef is correct, otherwise we agree with the restriction

[SludgeGirl]

Hmm learning more about how github handles force pushes and history rewrites, sorry that log is a bit of a mess ><

Anyway as part of this set of changes I've also updated instances of enumValues -> enumMember so that the wording is consistent with the bnf, let me know if there's anything further

[dragonmux]

class is struct above as while the keyword is class, the language defines them as structures-with-members so internally we've been using struct

[dragonmux]

There is an item that cropped up in this pass, but once that and the outstanding items from the previous are resolved, we think this is ready for merge - excellent work.

[dragonmux]

It comes down to: Do we want to only allow enums to contain enumeration values, or do we want to allow them to contain conditional logic, visibility statements, functions, operator overloads, etc?

One of the biggest problems C++ has always had with its enumerations (after fixing the scope problem) is there's no way to directly attach functionality to the type such as helpers to string-ify the enumeration values, and operators to help build complex values from enumerated values. If you agree that can make sense here, and given this current setup does allow visibility statements already, then we think checking for TokenType.enumDef is correct, otherwise we agree with the restriction

[dragonmux]

When you get to addressing the most resent review, please rebase against main so we can cleanly merge this with signatures kept intact