master Changelog
0.1
===
 - 0.1.7 Conditionally implement Configuration Cache compatibility
         I've figured out a way to get the JVM Aggregate Testing plugin to stay compatible with the configuration cache. Unfortunately, it involves the usage of an internal type. Here's what I'm doing to ensure that this doesn't backfire.
         A private method queries the test suite's implementation for a `Property<JvmTestToolchain<?>>`. It uses that property to return a `Function<Test, Provider<TestFramework>>`. While `TestFramework` is also internal, it has been stabilized while the `JvmTestToolchain<?>` type is an internal implementation of `jvm-test-suite`, which is an incubating plugin.
         The other thing is that this configuration cache compatibility can only be fulfilled if the participating project itself uses the `jvm-test-suite` plugin. I've already done the work to do this on our own projects, such as AccessTransformers, Unsafe, and Logging Utils.
 - 0.1.6 Change task groups to hide extra tests
 - 0.1.5 Disable the configuration cache when using aggregate testing
         In order for JVM aggregate testing to function, the test framework from the parent test task needs to be passed down to all of the child JVM-specific test tasks. This `TestFramework` property is a `@Nested` property, so it cannot be serialized or shared between tasks as that would cause a link between them.
         Aggregate testing is not automatically attached to the `check` or `test` base tasks, so this is not a big deal.
 - 0.1.4 Remove AggregateTest#getInput from public API
         This input folder cannot be modified since it is hard-coded to be where all the child JVM-specific test tasks output their reports.
 - 0.1.3 Fix aggregate test results not generating
 - 0.1.2 Fix default task directories not being created
 - 0.1.1 Fix extension using incorrect name
 - 0.1.0 Initial commit