Loader Bikeshedding Draft

Patchwork

        - Forge mods are remapped, patched, and loaded as full-class Fabric mods.
        - Forge mods can be placed in the "mods" folder directly without any issues.
        - Forge mods are not replaced, but instead the patched mods are kept in a cache somewhere else.
What we need:
        - Two new stages that happen before mixins are applied: "discovery" and "addition" (todo better name for the latter)
        discovery: 
                - Happens after all valid Fabric mods are put on the classpath, but before non-fabric mods are added to the classpath
                - Patchwork specifically needs an option to exclude certain jars from being added to the classpath.
                - Called "discovery" because this is the stage both Patchwork and Spungbric will use to find the jar files they need to do something with.
        addition:
                - Happens before mixins are applied, and after the discovery entrypoint.
                - Patchwork will patch and cache its Forge mods in this stage. (flexible) 
                - Patchwork will present jars (preferrably through a FileSystem) to be loaded by Loader. These mods will be loaded just like any other mod with all features available (mixins, AWs, etc.) except the discovery and addition stages
Additional things:
  - JimFS support is not completely neccisary but allows us to work with the system currently in Patcher. Apparently though it need some hacks to work accross classloaders, and it might not be possible (see: Jumploader)

Spunbric

Sponge Plugins are to be loaded as fabric's `ModContainers`.
        Mainly for allowing `isModLoaded(String)` checks
        Also exposes fabric mods and MC as Plugins to Sponge API.
    
    It must be possible to represent fabric's `ModContainer` as a `PluginContainer`
    CANNOT USE MIXIN SINCE FABRIC LOADER EXISTS TOO EARLY TO DO THAT.
        Idea: A sort of `ModContainer.ViewFactory<T>` which is a `Function<api.ModContainer, T>`, registered in `api.FabricLoader`
            To convert to a view, `ModContainer#as(T) -> T throws IllegalArgumentException`.
            These views are prebaked and cached.
            It's one solution to representing fabric mods that already exist as `ModContainers` as Sponge's `Plugin Container`

    Plugin Loading:
        We would init sponge's launch system within `preLoad` state.
        We need to parse the `mcmod.info` Sponge Plugins are expected to have. This is how we detect sponge plugins.
            We need to bind a ModContainer to a plugin's instance (which is an object) if it is a sponge plugin, this is for Sponge's PluginContainer for the `getInstance() -> Optional<?>` call
            
            If any fabric mods bundle a sponge plugin for compat or hooks, they are considered as part of the `fabric` mod's mod container, we just need to run our `ClassAnnotationVisitor` across the entire classpath to find those straggling classes with a `@Plugin` annotation.

    // Possible capabilities, these may actually never be implemented, so these shouldn't be prioritized.
    Future Capabilities (May not be implemented immediately or at all):
        Allow loading of plugins with existing Mixin Configs:
            Some sponge plugins can contain mixins. However we need to remap the jar using TinyRemapper and the mixin refmaps to handle that case.
            - Would mean we need a way to intercept and prevent the direct raw loading of sponge jars, preferably to use the remapped jar.