Add multi-release optimised methods for LogUtils

[PaintNinja]

Adds multi-release support for LogUtils to use a couple of more optimised methods that aren't available in Java 8.

String#repeat(int)
Should hopefully be self-explanatory... it's a more optimised variant of the StringBuilder approach that takes advantage of internal fields and methods inside the String class.

Map#entry(K, V):
Previously, a CapturedMessage POJO was used. This works fine and is straightforward, but its final fields are not trusted and can't be treated as a Valhalla value class in the future.

By switching to Map.Entry, we can use new AbstractMap.SimpleImmutableEntry<>(key, value) on Java 8 which gives us the benefit of trusted final fields (due to its final fields being defined inside JDK internals). On Java 11, we can use Map.entry(key, value) which additionally has the benefit of being marked with @jdk.internal.ValueBased, meaning we get the benefits of Valhalla value classes when running on a capable JVM.

[LexManos]

Main issue is project layout the code looks fine to me.

[LexManos]

SourceSets for multi-release jars dont work in a lot of ides (anything except intellij) so the proper way to do it is to have the java11 code in a sub project.

[Jonathing]

That is fine. I've seen this done in several different ways so I want to make sure that we just stay consistent moving forward, and I'd like to do it in a way that is as Gradle-friendly as possible.

So, my thinking for the main project is this:

tasks.named('jar', Jar) {
    into('META-INF/versions/11') {
        from project(':log-utils:java11').tasks.named('compileJava')
    }
}

Then, in each of the subprojects, depend on implementation rootProject.

[Jonathing]

The code block is just a sketch, I'd probably use whatever the cleanest solution is. I'm sure there is a way to reference a subproject with respect to the current project (i.e. subprojects['java-11'] = project(':log-utils:java-11')).

[LexManos]

Im fine with whatever way gradle wants it to be done.
I dont know how to do cross project merging.
But because non-intellij (yes, eclipse) IDEs dont separate dependencies/java deps on a sourceset level it is better to split everything into sub-projects.

Similar to how i've split AccessTransformer/ModLauncher/SecureModules (etc) tests into sub projects.

So ya, sub-projects rather then sourcesets if it is a different set of dependencies/java targets.

[Jonathing]

This PR is fine, just give me time to review the project setup so I can clean it up and/or take note of it for future projects. My goal is to make all of our projects as similar as possible so we don't run into inconsistencies when dealing with them in IDEs or at build time.

[LexManos]

Ya, I have no issue with the content of the PR, just the project layout.
Which isn't super important (Read: I don't want to block the PR's intake) just something on the cleanup todo list.
So i'll leave it to you two to decide when to pull.

[Jonathing]

Not sure how I forgot about this one. Found it in my notification list. Only blocker for this is to use projects instead of source sets. Not super important, but I'll put it on the todo list.

[LexManos]

If you could figure out how you want to do this, and then ping me with it sunday night/monday. I need a template for how to make gradle happy with multi-release jars properly. Or more specifically, with how to include sub-projects in the main project. Will start work on thing that shall not be named when i get back into town.

[Jonathing]

Not sure entirely what you mean by including subprojects in the main project, but yeah, we can do that.

[LexManos]

The output of a sub-projects compile (or jar task) in the parent's jar, so that gradle caching/tasks are happy.

[Jonathing]

Easy enough. See you then.