Design MethodScript casting behavior

# Introduction
When static analysis is enabled in the MethodScript configuration, MethodScript code will be typechecked. For scripts that are fully statically typed (i.e. all variables, procedures and closures are declared with a type / parameter types and return type), it should be impossible for a type to accidentally be used as a different type (which is called type safety of a program). When a type error occurs, it will be a compile-time error that can't be missed by the programmer. This is a powerful feature that can prevent many user mistakes.

## TODOs / Problems in the current typechecking implementation
The following features are currently missing in the typechecking implementation (this list might not be complete):
- ~Procedure arguments are not typechecked against their parameter declaration types.~
- Closure arguments are not typechecked against their parameter declaration types. This often won't be possible since the closure signature is not part of the closure data type.
- ~Procedure and closure return types are not typechecked (the type of `@value` in `return @value` against the declared return type).~
- Many functions do not yet have a `getSignatures()` implementation (that is used for obtaining type info for typechecking).
- There exists no way to cast values to any other specific type.

The last point in this list is the most severe problem with typechecking. Without a cast operator, it becomes impossible to fully statically type many programs. Lets say a function return `mixed` and you know from the documentation of that function that it will return an `int` for your usage, then a cast is necessary to convert the `mixed` value into an `int` value before it can be used as an `int`. If the cast is omitted, it will result a compile-time type error.

This issue exists to document the result of discussions around the implementation of multiple types of casts in MethodScript.

# Proposed casting design
## Cast types
Three casting types are proposed:

### [IMPLEMENTED] Explicit non-converting "soft" casts.
Syntax: `(type) val` (i.e. `(int) @val`).
This cast is mainly a compile-time check that tells static analysis what the type of a value is. In runtime, it will check whether the given value really is an (indirect) instance of the type that it was cast to and throw a `CRECastException` if it is not. This type of cast is merely a check and will never adjust the passed value in any way.

### Explicit converting "hard" casts.
Syntax: ` val as type` (i.e. `@val as int`).
This cast acts like a "soft" cast with the additional behavior that it converts the passed value into the casted-to type only if such conversion is both necessary and possible (i.e. `123 as string` will result in string `'123'`, `'45' as int` result in int `45` and `123.45 as int` will result in int `123`). Such a conversion can be lossy and irreversable. When the passed value is not instance of the passed type and conversion is not possible, a `CRECastException` is throws.

### Implicit converting casts.
Syntax: None.
This cast will occur when a type is used as a more wide type (i.e. a `uint8` value used as a `uint16` in C). in MethodScript the use-cases for this cast are very limited, but not irrelevant. This cast will allow using any `int` value as a `double`. A consideration can be to only allow usage of `int` literals where a `double` type is expected, and not allow this in the general case.

# Proposed casting implementation
The three types of casts as well as the other listed open problems can be implemented completely separately. Proposed priority is:
- [IMPLEMENTED] Explicit non-converting "soft" casts.
Adds possibility to statically type scripts without getting stuck on the lack of a cast operator.
- Function signatures of many functions (basic MethodScript functions such as the Math and DataHandling functions have priority).
Allows the type checker to check more commonly used code and cause more needs for casting in the process.
- [IMPLEMENTED] Procedure parameter typechecking.
Allows the type checker to check more code and cause more needs for casting in the process.
- Implicit converting casts.
This is likely easy to hack into the type checker if this will really just allow usage of `int` values as `double`.
- Explicit converting "hard" casts.
This cast is the hardest to implement due to the need for a good code structure that allows conversion between many different types in such a way that future MethodScript user objects can conveniently make use of the same code structure. Essentially this should follow the behavior of currently implemented conversion methods in the `ArgumentValidation` class.

# Relevant pull requests
- #1401
- #1402
- #1420