MergeJarsTask should be an AbstractArchiveTask

[triphora]

This way, it can be used more easily in Minotaur, for example.

[3TUSK]

We encountered the exact same issue in Longjing as well.

See this workflow run for more logs: https://github.com/teaconmc/Longjing/actions/runs/5453959652/jobs/9923451690

Log excerpt:

* What went wrong:
Execution failed for task ':teaconLongjingProcessing'.
> assert targetTask.get() instanceof AbstractArchiveTask
         |          |     |
         |          |     false
         |          task ':mergeJars'
         provider(task 'mergeJars', class io.github.pacifistmc.forgix.plugin.MergeJarsTask)

* Try:
> Run with --info or --debug option to get more log output.
> Run with --scan to get full insights.

In Longjing, we assume that each project will produce exactly one jar (and if the project produces > 1 jars, we pretend that all other jars do not exist); to find out where the jar is, we further assume that, there is always an AbstractArchiveTask that produces a ready-to-use jar. This has been proven to be the case for almost all standard and non-standard scenarios:

• Projects using ForgeGradle
• Projects using Fabric Loom, Quilt Loom or Architectury Loom
• Multi-project or multi-loader setup (where we support specifying a specific subproject to use)

The fact that MergeJarsTask is not AbstractArchiveTask breaks our assumption.
I have done some preliminary investigation; it appears that hard-coding some special casing on our side seems possible, but with unknown quirks.

I will give more updates once I have more info to share. Still, I personally believe this should be addressed on Forgix's end.

[Ran-Mewo]

I still have no clue how to turn the task into an AbstractArchiveTask
can't figure out a way to detect all projects and their jars and have the task somehow return a single JarFile