…#1296)

- Move instanceof logic from SA to InstanceofUtil. The new generics check here is questionable as the actual generic geclaration from instanceofThis is never used, and some other LeftHandGenericUse is passed in instead. This could use a revision that is out of scope for this commit.
- Fix SA instanceof `(CClassType, CClassType)` method signature being redirected to the `(Mixed, CClassType)` instanceof method, effectively making all types `ClassType` instead of their actual type.

Co-authored-by: LadyCailin <[email protected]>

Unit tests fail pretty hard, still needs debugging.

This completes the generics backend, though it will be a while before
the frontend part is ready.

LeftHandSideType is a class that is similar to CClassType, but can
contain left hand side semantics. Particularly, it can contain type
unions, and LHS generic statements. As all CClassTypes are valid LHS
identifiers though, tight coupling has been added to convert from
CClassType to LHS notation easily. In general though, most parts of the
type system work with LHS types now, though future use cases (such as
the new keyword) will specifically work only with CClassTypes. Both the
runtime and the SA framework have been adjusted to use LHS types now
instead.

Also, add back no-env methods in Static for now. These are deprecated,
but will give a phase in period for extensions to adapt, rather than
having a hard break right now, while the underlying thing (user objects)
isn't ready yet anyways.

Fix `and()` signature to remain compatible with its optimization. Ideally, we would require at least two arguments in `and()` and optimize a single-value `and()` to a `cast(<arg>, Booleanish)`, but such a function does not yet exist.

…to genericsTake2

This will be used in for instnace `array<string>("asdf", "fdsa")` to
hold the `string` value. Most functions won't use this, but there's no
other good way to shove this into existing arguments. Runtime
compatibility has been kept for existing extensions, but those with the @OverRide
annotation will fail on next build.

This is required for functions that return a typename, because the
return type of `T get_value<T>(...)` is not actually `T`, it's whatever
type the user specified (or implied) in the call. So
`get_value<int>(...)`'s return type is int, which is what the
typechecking needs.

This is currently supported through signatures, but was not being
resolved properly before returning up the stack.

Also, add more human readable data to the annotation, to help remember
when it was added.

…oval

The annotation now allows for a deprecation version field, which, if the
current version is less than that, will cause it to do nothing. Then,
when the version is bumped up, it will automatically start to be
aggressively deprecated. This allows for deprecations to be made at any
point in the release cycle, without actually changing the behavior, but
then on version bump, all the deprecations automatically take effect.

Also, prepopulate inferred function generics if they weren't explicitely
provided. This is only available with static analysis, but allows for
generic parameters to start being used in some scenarios.

This changes the declared type (not to be confused with the actual type)
of constants to auto in non-strict mode, and their actual types in
strict mode. This is necessary, because currently, code such as `'123' >
10` is supported, and needs to continue to be supported into the future.
However, adding typechecking to functions will start to break this code,
which is undesireable. Therefore, in non-strict mode, constants will be
declared as type auto.

Additionally, for functions that end up matching multiple signatures,
instead of returning the type union for possible return values, it now
returns auto, if any of the parameters are auto. This prevents further
type errors up the chain when signatures might be ambiguous. For
instance, if we have both array func(int) and int func(string), then in
non-strict mode, `func(@auto)` would be ambiguous. However, since the
parameter is auto, the user has already indicated that they are ok with
deferring typechecking until runtime anyways, so we prevent requiring a
cast in this case by returning auto, so `array @A = func(@auto)` will
also continue to work with no casts. This behavior is the same in both
strict and non-strict mode, but is more likely to be triggered in
non-strict mode due to the fact that constants are auto.

A few bugs were fixed with strict mode and centry, as well as when
unknonwn functions are found in certain cases.

This reverts commit 48d21b6.