Add support for build-time squashing/flattening

[PaintNinja]

Forge's JarJar supports recursion, meaning an embedded dep may itself embed additional deps, and therefore requires checking all embedded jars just in case they might also embed more jars.

In new loader, recursion is not supported as it's relatively slow and adds unwanted complexity. Instead, we need to flatten embedded jars at build time. For example...

Before:

- foo.jar
    - bar.jar
        - bar-core.jar
        - bar-extra.jar
            - baz.jar

After:

- foo.jar
    - bar.jar
    - bar-core.jar
    - bar-extra.jar
    - baz.jar

[LexManos]

So my main concern about this is that we would then be either duplicating data or modifying an existing archive when bundling.

Neither of which is a good idea in my opinion.
So would it be sensible to instead only flatten the metadata?
Do the resolution pass to gather the selected archives and then extract just those.
With ROIMFS the actual extraction/management shouldn't be a performance issue.
I think the candidate discovery is the main issue.

So the file structure would still be:

- foo.jar
    - bar.jar
        - bar-core.jar
        - bar-extra.jar
            - baz.jar

but the metadata would be:

foo.jar!/META-INF/jarjar/metadata.json
  - bar:1.0 - META-INF/jarjar/bar.jar
  - bar-core:1.0 - META-INF/jarjar/bar.jar!/META-INF/jarjar/bar-core.jar
  - bar-extra:1.0 - META-INF/jarjar/bar.jar!/META-INF/jarjar/bar-extra.jar
  - baz:1.0 - META-INF/jarjar/bar.jar!/META-INF/jarjar/bar-extra.jar!/META-INF/jarjar/baz.jar

These wouldn't be read, but to illustrate:

foo.jar!/META-INF/jarjar/bar.jar!/META-INF/jarjar/metadata.json
  - bar-core:1.0 - META-INF/jarjar/bar-core.jar
  - bar-extra:1.0 - META-INF/jarjar/bar-extra.jar
  - baz:1.0 - META-INF/jarjar/bar-extra.jar!/META-INF/jarjar/baz.jar

foo.jar!/META-INF/jarjar/bar.jar!/META-INF/jarjar/bar-extra.jar!/META-INF/jarjar/metadata.json
  - baz:1.0 - META-INF/jarjar/baz.jar

Also as it was asked on discord, I think we should keep the hardcoded META-INF/jarjar/metadata.json path for the metadata file. Instead of reading it from the MANIFEST.MF. As I don't see any reason to allow it to be configurable. Keeping it hard coded is simpler.

The Paths inside the json however are already configurable and can point anywhere hence why I think flattening the metadata would be simplest:
Real world example:

{
  "jars": [
    {
      "identifier": {
        "group": "com.example",
        "artifact": "mod-inner"
      },
      "version": {
        "range": "[1.0,)",
        "artifactVersion": "1.0"
      },
      "path": "META-INF/jarjar/jarjar-example-mod-inner-1.0-all.jar",
      "isObfuscated": false
    },
    {
      "identifier": {
        "group": "io.github.llamalad7",
        "artifact": "mixinextras-forge"
      },
      "version": {
        "range": "[0.4.0,)",
        "artifactVersion": "0.4.0"
      },
      "path": "META-INF/jarjar/mixinextras-forge-0.4.0.jar",
      "isObfuscated": false
    }
  ]
}