Add support for MixinExtras expressions

[Earthcomputer]

See Llama's gist for a (slightly outdated) overview of what MixinExtras expressions are. Without IDE support, ME expressions would be really inconvenient to write, more so than other mixin features.

ME expression syntax is support through a custom language in IntelliJ, through the use of language injection. To make this nicer to work with, I have slightly extended the ME expression language. Definitions are prefixed with the class keyword, and then a boolean literal for whether they are a type or not. Expressions are surrounded with do { ... }. For example:

@Definition(id = "Integer", type = Integer.class)
@Definition(id = "x", local = @Local(type = Object.class, ordinal = 0))
@Expression("(Integer) x")

would produce the following injected ME expression file:

class true Integer
class false x
do { (Integer) x }

This feature is basically done now, the only thing left is to switch away from the JitPack version of MixinExtras and use the library they'll provide for us, which will hopefully have the same interface.

Don't worry about the amount of commits, I'll squash them all on merge.

[DenWav]

Well this PR is insane. I don't really know anything about MixinExtras, and can barely follow parts of this PR, and can't follow other parts at all. The code seems fine, it's just going over my head in the more complicated places, but I don't have a problem with trusting you. I did look at (most) of the code in this PR at least, even if I don't really know all of what's going on.

I apologize that the only comments I have are unimportant nitpicks, again I'm going mostly on trust here. Get the tests passing and address these and I'm happy to call this one good to go.

[RedNesto]

This looks really good.

I don't have much to say about the features added as I'm not familiar with MixinExtras.

Also not sure about those invokeLater { WriteCommandAction[...] } patterns. It might be the only way to achieve this today, but it might age poorly because of https://youtrack.jetbrains.com/issue/IJPL-53

[RedNesto]

Nitpick: why is this not with the other ME EPs a bit further down?

[RedNesto]

This is not super consequential, but using Kotlin's withLock extension function avoids that Java try/finally-unlock boilerplate.

[Earthcomputer]

It didn't let me do this for some reason, prompting me to add kotlin stdlib to the classpath, but don't we already have stdlib-jdk8?

[LlamaLad7]

Perhaps more to the point kt also has ReentrantReadWriteLock().read { } and a similar write method.

[Earthcomputer]

I think once write actions are allowed outside of the EDT we'll have to make a general sweep of the codebase to look for cases like these where we use invokeLater for write actions.