SkriptParser refactor, add ParsingConstraints

[sovdeeth]

Problem

The SkriptParser class is a sprawling mess. There's multiple versions of the same method doing different things, 7 different ways to parse something, and a very limited ability to tell it what exactly you want it to parse. You can supply an iterator of syntaxes to attempt, but that can become hard to construct if, say, you want a section that doesn't allow functions, but within that you want another section that only allows things that return String. These constraints are hard to manage and are fully the responsibility of the caller, who may not be aware of existing constraints.

Constraints also exist in the form of a set of bitmap flags, which are clunky and poorly documented at the best of times.

Solution

The goal of this PR is to provide a new class, ParsingConstraints, that holds all the information necessary to constrain a parse to the user's desire. It provides control over whether functions are allowed, literals, non-literals, and even provides methods to only include or specifically exclude certain syntaxes via their class.

Since this requires a significant rework to the internals of SkriptParser, I am also taking the time to refactor the class significantly. The new parser will be in the skriptlang package and rebuilt from scratch, with complexity moved out to other classes like ExpressionParser and FunctionParser. The old SkriptParser class will remain for backcompatibility, but I will have all its methods redirect to calls to the new parser.

The design focuses on having parser interfaces to make future refactors/implementations simpler, and to allow more separation of logic. The core is SyntaxParser, which handles the generic parsing loop of matching a pattern to an iterator of syntax infos. Specific parsers will build on top of that, like ExpressionParser, which provides methods for specifically parsing expressions properly, like literal handling and variable parsing. API users should vastly prefer using specific parsers when available, as is currently done with things like Statement.parse(). SyntaxParser is a building block, not a complete tool.

Various parsers will be easily converted between via static from(SyntaxParser<?>) methods that copy over constraint, context, and input info so you can easily go from trying to parse as a Function to an Expression using the same parsing situation.

Testing Completed

Supporting Information

• redo generic parse()
• redo single expression parsing
• redo expression list parsing
• redo function parsing
• ensure parsing constraints are accessible down the parsing tree and can be compounded easily.

---

Completes: none
Related: none