WXYZ property and handler reorganization

[sovdeeth]

Problem

Many things have coordinates. Vanilla Skript includes 3 currently, Location, Vector, and Quaternion, though Chunk should also be included. Unifying these under a single property removes the confusion of x component vs x coordinate and allows many more types to use the x of syntax.

Solution

Adds a property for WXYZ components, where the handler is able to declare which axes it supports.
I've also tried to sneak in 40 other files worth of reorganization changes, moving Handlers out to their own classes to avoid another massive DefaultX-like class. These have no functional impact, and can mostly be ignored when reviewing.

I decided on a combined WXYZ property for boilerplate's sake. I had a separate property for each axis, which does lower complexity for each individual handler, but leads to a lot of duplicated code between each one for each class. Since most things in Skript will deal with at least 2 axis and normally 3 or more, I thought it simpler for the user to just combine the property into one. If anyone has good arguments against this, I'm all ears.

Testing Completed

All prior behavior is maintained via existing tests. Manual testing confirms interactions with things like player velocity.

Supporting Information

Breaking changes: removes [vector|quaternion] from the component syntax (vector x of {var})

---

Completes: none
Related: none

[Efnilite]

will take a closer look later, looks good on first glance

[Absolutionism]

Since this is targeting dev/feature, shouldn't the usages of
if (!SkriptConfig.useTypeProperties.value())
be removed? As the 2.13 release message stated properties were fully coming out in 2.14

[sovdeeth]

Since this is targeting dev/feature, shouldn't the usages of
if (!SkriptConfig.useTypeProperties.value())
be removed? As the 2.13 release message stated properties were fully coming out in 2.14

I don't want to do that until we're sure properties is ready for full release, so it'll be a different pr