feat: allow for specifying ATs for upstream sources

[Toffikk]

These changes provide fork developers with a way to specify an AT file (or have it detected automatically) for upstream sources, such as paper-server and paper-api for a fork of Paper. This allows fork developers to benefit from using ATs while modifying these sources without needing to clutter patches, with lots of manual access transforms, and as such this greatly improves the overall comfort of making more involving changes, in the sources. It also allows for fork devs to be able to organize ATs in one place which makes it easier to review later.

The implementation proposed in this commit works as follows:

1. Derive the location of the build-data dir from the output dir specified in the PatchRepo/Directory's config.
   • This sounds like it should be ideally derived from either the Project instance or Layout by injecting, however we cannot do it this way, as the upstream server projects are set up in the fork’s server project, not as part of the upstream setup like API is, meaning they either can’t access their ATs or other issues appear. The layout approach has even more downsides as it inherits the downsides of the aforementioned approach and the build-data dir would be forced to appear in the server project.
   • Therefore, I believe using the outputDir to calculate the possible root project is the best way to make it work, as it works on fork setups and doesn’t cause issues, and we can also safely assume that it will work for everyone as every fork and fork template is following the convention of specifying their outputDir’s in a subfolder of the root project, and regardless it can be overrode like the minecraft AT file currently can be so this is correct in practice.
2. Search for an AT file, by the name of the patch repo/directory as specified.
3. Apply them before applying source patches.

The locations in steps 1 and 2 can be overriden per patch repo/directory by just overriding the val.

In order to achieve this change, we introduce a new task, with its implementation sitting in SetupForkUpstreamSources which applies those ATs. Everything else not explained here or even explained should follow the behaviour of AT application for minecraft sources.

The change has been tested in production in an organisation fork of paperweight for over 6 months with both a nested fork project that uses them heavily and then fork projects depending on the nested fork project, and no issues have been reported or arose, so i'm confident that this implementation will work properly.

For additional reference:

• weaver -> where this impl was implemented first and tested
• Baguette -> an example fork using this feature

[Toffikk]

note: if #376 gets merged before this, this pr needs to be updated,
however if this gets merged first, then the other pr needs to be updated.
(i already have the proper changes on my local fork)