Add new @Pattern feature to centralize version-aware code

That is, most of the business code should not be aware that it is being compiled
to multiple versions even when it heavily interacts with MC, preprocessor
statements should be an escape hatch, not the norm.
Similarly, code should not be forced to do `MCVer.getWindow(mc)` instead of the
much more intuitive `mc.getWindow()`, and this new preprocessor (technically remap)
feature makes this possible by defining "search and replace"-like patterns (but
smarter in that they are type-aware) in one or more central places which then
are applied all over the code base.

In a way, this is another step in the automatic back-porting process where
preprocessor statements are used when we cannot yet do something automatically.
Previously we "merely" automatically converted between different mapping, this
new feature now also allows us to automatically perform simple refactoring
tasks like changing field access to a getter+setter (e.g. `mc.getWindow()`), or
changing how a method is called (e.g. `BufferBuilder.begin`), or changing a
method call chain (e.g. `dispatcher.camera.getYaw()`), or most other
search-and-replace-like changes and any combination of those.
The only major limitation is that the replacement itself is not smart, so
arguments must be kept in same order (or be temporarily assigned to local
variables which then can be used in any order).

1 files changed, 18 insertions, 0 deletions

diff --git a/README.md b/README.md
index f564ab0..cfbb54b 100644
--- a/README.md
+++ b/README.md
@@ -4,6 +4,24 @@ To support multiple Minecraft versions with the ReplayMod, a preprocessor is use
 To keep preprocessor statements to a minimum and support changes in mapping (of originally obfuscated Minecraft names), the preprocessor additionally supports
 source remapping of class, method and field names implemented in the application through use of an embedded IntelliJ IDEA (Java and Kotlin sources are supported).
 
+Additionally, it supports defining simple "search and replace"-like patterns (but smarter in that they are type-aware) annotated by a `@Pattern` (configurable) annotation in one or more central places which then are applied all over the code base.
+This allows code which would previously have to be written with preprocessor statements or as `MCVer.getWindow(mc)` all over the code base to instead now use the much more intuitive `mc.getWindow()` and be automatically converted to `mc.window` (or even a Window stub object) on remap if a pattern for that exists anywhere in the same source tree:
+```java
+    @Pattern
+    private static Window getWindow(MinecraftClient mc) {
+        //#if MC>=11500
+        return mc.getWindow();
+        //#elseif MC>=11400
+        //$$ return mc.window;
+        //#else
+        //$$ return new com.replaymod.core.versions.Window(mc);
+        //#endif
+    }
+```
+All pattern cases should be a single line as to not mess with indentation and/or line count.
+Any arguments passed to the pattern must be used in the pattern in the same order in every case (introducing in-line locals to work around that is fine).
+Defining and/or applying patterns in/on Kotlin code is not yet supported.
+
 This is not integrated into the preprocessor itself for essentially two (now historical) reasons:
 - License incompatibility between the GPL used in the ReplayMod (and the preprocessor) and the EPL used by the JDT
 - Lombok requires a javaagent to work for the JDT, so we need to fork off into a separate JVM anyway