[7.0] Migrate Mavenizer to ValueSource

[LexManos]

Long story short the Configuration cache is a fucking nightmare.
All dependencies are resolved before any tasks are run when using the configuration cache if they are used as part of a task's configuration.
The recommended solution from Gradle's slack is to migrate to using ValueSource to create anything that needs to be used in the Configuration Cache.

This actually isn't to big of a deal, ValueSource's are given access to ExecOperations which can launch java processes.

The ToolChainService can resolve toolchains during configuration time.
Detached Configurations can resolve interdependence during ValueSource time, so we can resolve our tools.

Changing minecraft.dependency to return a Provider allows us to force invoke our ValueSource's obtain method before the Minecraft dependency is even told that it exists to Gradle. this should once and for all force Mavenizer to run before any dependecy it creates is asked for.

The only real weirdness is that we can not resolve SourceSets that our dependency is being used in to magically find the accesstransformer.cfg file. So I just search ALL source sets.
This can cause weird behavior, but modders can work around that by doing something like:

dependencies {
  implementation_1_21_11 minecraft.dependency('net.minecraftforge:forge:1.21.11') {
    accessTransformer = file('src/1_21_11/resources/accesstransformer.cfg')
  }
  implementation_1_20_1 minecraft.dependency('net.minecraftforge:forge:1.20.1') {
    accessTransformer = file('src/1_20_1/resources/accesstransformer.cfg')
  }
}

Also I did express concerns about ordering of the buildscript's repository blocks.
This seems to work fine:

repositories {
    maven minecraft.mavenizer
    maven fg.forgeMaven
    maven fg.minecraftLibsMaven
    mavenCentral()
}

dependencies {
    implementation minecraft.dependency("net.minecraftforge:forge:$minecraft_version-$forge_version")
}

repositories {
    maven { name = 'Test', url = 'https://testing/shit/' }
}

I added some temporary debug printing to illustrate things:

> Configure project :
ForgeGradle 7 is an incubating plugin.
Java: 21.0.1, JVM: 21.0.1+12-LTS (Eclipse Adoptium), Arch: amd64
Access Transformer: Z:\Projects\MDKExamples\FG7-traditional-1.21.10\src\main\resources\META-INF\accesstransformer.cfg
Executing Mavenizer:
  Classpath: C:\Users\Lex\.gradle\caches\minecraftforge\forgegradle\tools\mavenizer-0.4.19.jar
  Java: C:\Users\Lex\.gradle\jdks\eclipse_adoptium-25-amd64-windows.2\bin\java.exe
  Arguments: --maven
             --cache C:\Users\Lex\.gradle\caches\minecraftforge\forgegradle\mavenizer\caches
             --jdk-cache C:\Users\Lex\.gradle\caches\minecraftforge\forgegradle\mavenizer\caches
             --output Z:\Projects\MDKExamples\FG7-traditional-1.21.10\build\minecraftforge\forgegradle\mavenizer\output
             --artifact net.minecraftforge:forge
             --version 1.21.10-60.0.17
             --global-auxiliary-variants
             --access-transformer Z:\Projects\MDKExamples\FG7-traditional-1.21.10\src\main\resources\META-INF\accesstransformer.cfg
             --repository MinecraftForge,https://maven.minecraftforge.net/
             --repository Minecraft libraries,https://libraries.minecraft.net/
             --repository MavenRepo,https://repo.maven.apache.org/maven2/
             --repository Test,https://testing/shit/
Minecraft Maven is up-to-date, took 0:01.206
Access Transformer: Z:\Projects\MDKExamples\FG7-traditional-1.21.10\src\main\resources\META-INF\accesstransformer.cfg

Note that the repository list includes the one added after the dependency block
Also note that "Access Transformer" is written twice, this is because the parameters for the ValueSource is configured twice, this is a behavior of the ConfigCache, I don't really care to dig into it. The main thing is that the execution is only invoked once.

This should fix #1031 once and for all, while maintaining compatibility with Config cache. I'm able to continuously run gradlew clean && gradlew build and everything works.

There are some future cleanups that need to be done, Right now, SyncMavenizer still exists and still gets configured/envoked. I just nooped the TaskAction. Could cleanup a lot of config time stuff by de-implementing that task.

MinecraftDependencyImpl.handle can be removed.
All the flowScope stuff can probably be yeeted.
But thats all just future cleanup that in theory can be done without breaking DSL. So we can talk about after we get things functional and in production.

[LexManos]

Removed SyncMavenizer task.
Quieted down logging on normal runs (was mainly there for testing)
As soon as @Jonathing Sanity checks that it works on one of his machines.
Its ready to be pulled.

[Jonathing]

Related conversation on Slack: https://imgur.com/a/ZyjD6Le

These aren't meant to be receipts or anything, it's just to get around Slack's 90-day retention for non-paying users. It will be important to reference this later.

[Jonathing]

Build successful on macOS x64, macOS arm64, and linux x64.