Bridge Compiler Improvements and Unsafe

This draft contains a significant improvement to the bridge compiler, a new function entry and a change to the development model.

1. Feature-previews in Unsafe

A new unsafe function namespace has been added to ByteSkript.
This is unstable by design and is guaranteed to change between versions. It is designed to contain first-pass features that may be developed into syntax eventually, or may be moved to the stable and reliable skript namespace instead. Equally, these features may be removed without warning if they do not make it past the trial phase.

Features will now primarily be added to unsafe for one minor version before becoming a syntax.

The unsafe namespace will also contain some dangerous functions for manipulating internals that will live there long-term and will never be developed into syntax due to their native unreliability. (E.g. monitoring all script processes, locking and unlocking the fence on objects.)

2. Explicit Function Parameters

Functions may now have explicit parameter types. This is designed primarily for people interacting with third-party Java libraries, who need to match an exact method signature in order to override it.

function blob(name, age):
    parameters: string, integer
    return: boolean
    trigger:
        print {name} +"'s age is " + {age}
        return {age} > 31

In this example, the parameters will accept only a string and an integer argument. See section 3 for more information about type conformity.

It is acceptable to under-provide or over-provide parameter types, in which case the extras will be ignored.

This is currently incompatible with atomic parameters, which must accept atomic variables.

3. Type Conformity in the Bridge Compiler

ByteSkript's bridge compiler is now capable of automatically conforming a type when required.
This is part of an effort to seamlessly correct common mistakes without causing trouble for the user.

If a function or Java method requires non-object parameters, rather than simply casting or boxing the arguments, the metafactory will rewrite the code on-the-fly to include the correct call to the type converter.
Because the bridge compilation is done on-the-fly with direct insights to the types being used, it will only insert converters where they are needed to maximise the speed of the code.

function blob(name, age):
    parameters: string, integer
    trigger:
        assert {name} is a string
        assert {age} is a number

function test:
    trigger:
        run blob("hello", "3") // converts "3" to 3
        run blob(1, 3) // converts 1 to "1"

Full Changelog: 1.0.27...1.0.28