Implement type-aware function argument parsing

[APickledWalrus]

Problem

This PR addresses multiple issues. First, list parsing behavior is duplicated within SkriptParser rather than centralized in one method.

Additionally, since function overloading was added, literal parameters (for conflicting literals) would fail to parse properly (that is, as the expected type).

Consider the following example:

function literal_test(x: entity type):
# fails to parse as "firework" is mistakenly interpreted as an itemtype or visual effect,
# even though for a function call it would only ever be an entity type
literal_test(firework)

Solution

List parsing has been re-written. The underlying code/process is generally the same, just better formatted and organized. The handling of plural types (consider ExprInfo such as %number/booleans%) has been rewritten to work "properly". Previously, only the first argument was used. Now, the entire array is considered against the parsed expressions:

# consider %number/booleans%
# should succeed
true and true
true or true
1 or true

# should fail
1 and true
1 and 1

Function argument parsing has also been rewritten. Previously, function arguments were parsed as any possible expression (i.e. expecteing Object as the return type). Now, function arguments are parsed based on the possible parameter types. For all possible signatures, an ExprInfo is created for each parameter index. Consider the following example:

function test(x: string)
function test(x: boolean)

Now, when attempting to parse test(INPUT) it will only attempt to parse INPUT as a string or boolean, rather than any value.

Further testing of performance and stability is needed.

Testing Completed

The StructFunction test has been expanded with a test case for conflicting literal parameters.

Supporting Information

---

Completes: none
Related: none