[7.0] Add support for transitive injected interfaces with Facade

[PaintNinja]

AccessTransformers deliberately don't apply transitively because there's no easy way of knowing if MC had something public or if one of your dependencies changed it, which can result in unintended reliance on a mod's build time optional dependencies.

Interface injection on the other hand doesn't change existing code - it adds new methods to an existing class, and you can see where the methods are coming from because they're on the interface, not the class the interface is applied to. The risk of accidentally relying on another mod is reduced as they can see in their IDE that a new method they're referencing is coming from a non-MC package.

Some mods like GeckoLib heavily rely on interface injection to extend vanilla MC's APIs, as alternatives like utility methods and wrapping aren't as nice for API users to work with, are more effort to maintain and less performant. Currently mod devs need to setup Facade in their own project and manually check that their Facade config matches each of their deps in order to use them, it would be nice if injected interfaces applied transitively so that they'd work out of the box. It could also be handy for Forge, as some patches that inject interfaces could be replaced with a Facade config instead.

[LexManos]

At the time that facades are injected into mavenizer from FG there is no information about transitive dependencies.

I am also cynical/skeptical that the surfacing of where a method comes from is sufficient for modders to not fall into the accidental dependency trap. Im not a fan of any automated magic. I would have to see concrete examples of what you see as the discoverability.

However looking at the existing code, the whole chain should be able to support multiple facade config files as is. The problem becomes discovering/feeding them into fg.

Currently as they are purely a compile time tool there is no standardized location for the facade configs. (And no expectation that they are shipped in dev jars)

Perhaps we can add some form of generic fg.depFile('foo:bar:1 0', '/facade.cfg')

So that modders can opt-in to depending on the ijectected interfaces of dependencies by doing something like:

dependencies {
  implementation fg.dependency(forge) {
  facade = files(
    '/src/main/resources/facade.cfg',
     fg.depFile('foo:bar:1.0', '/facade.cfg')
    )
  }
}

Im pretty sure you can do that already using zipTree but a helper wouldn't be such a bad idea.

If we standardized the location of the file in the jar (or added a manifest entry to locate it) it could be even smaller. fg.depFacade('foo:bar:1.0') or fg.depFacades(configurations.hard_mod_deps)

In that vain, we could also add a similar "find the file in a dep" helper for AT configs for modders. Tho I would still recommend against that as there is no harm re-declaring the AT yourself.