Support composite builds when generating runs

[SquidDev]

This adds support for composite builds (i.e. includeBuild) to the various run generators.

As each included build is treated as a separate project, generating runs would read/write config from the non-existent <child project>/.idea rather than .idea (similarly for VSCode).

This change will walk up the entire project hierarchy to find the correct place to read/write IDE configuration. It also remaps the prepareXXX tasks to the "full" task path.

I've set up a test repository at https://github.com/SquidDev/fg-composite-demo/ which contains a mixture of projects using include and includeBuild. SquidDev/fg-composite-demo@c46e017 is the commit which switches run generations to this branch, to allow you to see before/after.

I'm marking this as a draft for now, as it will conflict with #868.

[LexManos]

Without looking too deeply into this, why cant we just use root project? Instead of having to walk, and then find root?

[marchermans]

Because included builds are registered differently in gradle.

They are considered loosly attached to the current project and behave weirdlh when it comes to the root and their parents

[SquidDev]

Without looking too deeply into this, why cant we just use root project? Instead of having to walk, and then find root?

Ahh, sorry! Should have explained this a little better.

The point of includeBuild/composite builds in Gradle is to put multiple standalone projects in the same workspace. This means that each included build is an entirely separate project root - the project root of an included build is just the included build, not the project which was doing including.

Most of the time that's what you want. However, run configurations are the one thing which need to know the whole workspace they're operating in, hence jumping through the additional hoops.

[LexManos]

Interesting, another weirdness of gradle. All I know is we use rootProject all the time in Forge itself which uses included builds. Same for ff, and eventbus.

[SquidDev]

Ahh, this is terrible nomenclature on Gradle's part. When you use include(...), rootProject is the right thing (as those are treated as subprojects). However with includeBuild(...) its not (as those are treated as entirely separate projects).

The actual motivation for includeBuild (and also this PR) is to allow you to use multiple standalone projects in one Gradle build - for instance running a local clone of Forge and a mod which depends on Forge as part of the same build.

[SquidDev]

Marking this as ready for review as #868 is held up.