Generation Passes modernization

[Mirsario]

Similarly to #2139, this is a proposal for modernization of everything related to generation layers.

Current Design

First, have a look at the common usage of the current (1.3) TML's generation pass designs:

public class WorldGenSystem : ModSystem
{
    // ...

    public override void ModifyWorldGenTasks(List<GenPass> tasks, ref float totalWeight)
    {
        int index = tasks.FindLastIndex(x => x.Name == "Settle Liquids Again");

        if (index != -1) {
            tasks.Insert(index + 1, new PassLegacy("ModularTools:Sulfur", (progress, configuration) => {
                progress.Message = "Crystallizing sulfur";

                foreach (Point poolLocation in Hooking.PoolLocations) {
                    if (poolLocation.Y > WorldGen.lavaLine) {
                        WorldUtils.Gen(poolLocation, new Shapes.Circle(10), new GenerateSulfurAction());
                    }
                }
            }));
        }
    }
}

(Taken from Itorius' ModularTools)

Why do anything?

These are the 'problems' that the following design will attempt to solve:

• The current usage & design involve boilerplate (like meddling with ModSystems) and leave too much in the hands of API users. For example: caching generation pass instances, writing layer insertion code defensively, etc. The former has likely never been done right, and the lack of the latter in mods has been a common pain for many years -- a ton of mods that add tooltips, which use the same design, have had many cases of conflicts with mods that remove or modify vanilla tooltips.
• The act of 'generating' anything is not generalized. This means that dealing with different vanilla generations is done through separate hooks that can be considered hardcode - ModifyWorldGenTasks, ModifyHardmodeTasks, with people having asked for ModifyAltarTasks, and with support for modifying meteor spawning also nowhere to be found.
• The previous problem also extends with the fact that the API does not support creation of custom generations by mods. Some content mods add custom meteors, and it's nothing crazy for addons to want to be able to add to them or modify them.

Proposal

Everything past this point may be incomplete and poorly written, somewhat of a sketch.

The suggested solution for the first problem is nothing unexpected by now - like with interface layers, we somewhat copy the design of player layers from #1047.

The latter two problems are solvable by making generations be instanced, and perhaps having generation types use the type system.

Here's a short, non-final summary of suggested changes:

Generation Passes:

• Make the GenPass (or a derivative) class a self-sufficient ModType, with ModSystem.ModifyInterfaceLayers hooks removed in favor of automatic registration.
• Make generation pass orders determined at load-time using topological sorting & anchors (all the required code is already there.)
• Create readonly static fields with wrappers of vanilla generation passes, exactly like within the Terraria.DrawStructures.PlayerDrawLayers class. PassLegacy class, or its constructor, would be turned internal.
• Replace removal & reordering of generation passes with hiding instead. The design from the aforementioned PR, where reordering would be done with hiding the original layer and adding a wrapper layer at the same position, seems to be working well.

Generation Types:

• Create a WorldGeneration class, instances of which will contain lists of enabled generation passes, copies of which will be further modified during generation starts.
• Create static Default, Hardmode, AltarSmash Meteor default generations as static { get; } properties on WorldGeneration, or WorldGenerations classes. Whatever sounds best?
• Create methods for running world generations with WorldGeneration instances, invoking hooks for toggling genpasses' appearance on them.

New usage sketch

Each genpass will be able to go into its own file, and enable themselves for initializing world generations. Types deriving from WorldGeneration will be able to modify their own default lists of enabled generation passes. Hooks (supposedly in ModSystems) will allow people will be the last to modify already defined visibility of genpasses on world generations.

public sealed class SulfurOreGenerationPass : GenPass
{
    public override Position GetDefaultPosition()
        => new AfterParent(GenerationPasses.SettleLiquidsAgain);

    public override bool GetDefaultVisibility(WorldGeneration generation)
        => generation == WorldGeneration.Default;

    protected override void ApplyPass(GenerationProgress progress, GameConfiguration configuration)
    {
        progress.Message = "Crystallizing sulfur";

        foreach (Point poolLocation in Hooking.PoolLocations) {
            if (poolLocation.Y > WorldGen.lavaLine) {
                WorldUtils.Gen(poolLocation, new Shapes.Circle(10), new GenerateSulfurAction());
            }
        }
    }
}

[Tyfyter]

If this is added I believe it would benefit greatly from passes being able to be positioned relative to single other passes which they don't rely on

[Chicken-Bones]

Previous discussion summary (scroll up for context): https://discord.com/channels/103110554649894912/445276626352209920/1011402588371038251