[Idea:preprocessor] Option to disable recursive resolving of `build.properties`, or to supply a `build.properties`

[Ampflower]

Is your feature request related to a problem? Please describe.

In Music Moods, a Minecraft mod that I've converted to use conditional compilation for multi-version & multi-loader, I opted to autogen build.properties along with other subproject files, and included a 'root' one for the IDE to use.

The problem is that when compiling, it'll recursively resolve build.properties up until, seemingly, the filesystem root normally, causing conflicting definitions to be present. An example would be MC_1_21_OR_NEWER and MC_1_19_OR_OLDER being present at the same time, despite being nonsensical and normally impossible. This can cause multiple, incompatible, branches of the code to be active at the same time, causing compilation errors at best case, or uncaught bad behaviour at worst case.

This can also be a problem if there happens to be a stray build.properties outside of the project that contains entries that can affect the state of the build.

Describe the solution you'd like

• The ability to ignore build.properties
• A way to supply a specific build.properties
• A way to tell the preprocessor to stop recursively resolving
  • Perhaps a manifold.root=true akin to how .editorconfig does it.

Describe alternatives you've considered

Honestly, I just wrote an agent to asm manifold.preprocessor.definitions.Definitions#findBuildProperties(IResource) into always returning null. This is not a good solution, but it works well enough for my use, since I manually pass -Abuild=property to javac anyways.

The alternative route is to not have a root build.properties for the IDE to use, but, then you have to deal with excessive errors either way, due to the way Stonecutter functions: by having the root src/ be driven by the 'active' subproject.

Additional context

This is mainly with generating subprojects on the fly, using Stonecutter as the project splitter, and a handrolled generator in settings.build.gradle to drive it.

This is less likely to occur in more normal scenarios, but, is something nonetheless.