feat: support switch-case replacements and definitions at root level

[TTtie]

Adds support for switch-case style replacement in message actions, inspired by pattern matching found in modern programming languages, for example (preliminary syntax, some details may be subject to change):

<message text="The outcome is {outcome}">
    <replacements>
        <!-- 
             value supports formulas and may be omitted 
             (in this case, the match attribute in <case>
             is disallowed)
        -->
        <switch id="outcome" value="variable">
            <!-- matches if the formula result is 0 -->
            <case match="0" result="Outcome 1"/>
            
            <!-- matches if the formula result is 1 AND only-team-1 allows -->
            <case match="1" filter="only-team-1" result="`aOutcome 2"/>
            
            <!-- matches if only-team-2 allows regardless of formula result -->
            <case filter="only-team-2" result="`bOutcome 3"/>
            
            <!--
                full syntax (matches if the formula result is between 2 and 5,
                and the inner filter allows)
            -->
            <case>
                <match>2..5</match>
                <filter>
                    <all id="not-moving">
                        <variable var="player.vel_x">0</variable>
                        <variable var="player.vel_y">..0</variable>
                        <variable var="player.vel_z">0</variable>
                    </all>
                </filter>
                <result>`cOutcome 4</result>
            </case>
            
            <!-- a fallback value if no cases match (defaults to an empty component) -->
            <fallback>`dA fallback outcome</fallback>
        </switch>
    </replacements>
</message>

Additionally, replacements can now be specified at the root level:

<map>
    <replacements>
        <!--
            scope is required for all replacements except <player />
            and it will be enforced if specified
        -->
        <decimal id="decimal" value="money" scope="player" format="0.00"/>
        <switch id="team" scope="team">
            <case filter="only-team-1" result="`aLime"/>
        </switch>
        
        <!-- This will error as only-team-1 is team-scoped -->
        <switch id="team2" scope="match">
            <case filter="only-team-1" result="`aLime"/>
        </switch>
    </replacements>
    <actions>
        <action id="action" scope="match">
            <switch-scope inner="player">
                <message text="The variable is {variable} and your team is {team}!">
                    <replacements>
                        <!--
                            the syntax for replacement references is
                            <replacement id="local-id">global-id</replacement>
                        -->
                        <replacement id="variable">decimal</replacement>
                        <replacement id="team">team</replacement>
                    </replacements>
                </message>
            </switch-scope>
        </action>
    </actions>
</map>

[Pablete1234]

You're not replacing you're creating a component, so i feel calling this method replace is a bit misleading
Maybe create or get would fit better

[Pablete1234]

You can likely get away with not having a scope, but rather a checking function, since some replacements dont need any specific scope.

Think of it in the same spirit as respondsTo in filters.

Reason behind this is that if a replacement works for Match it should also work for party or player, there's no reason it shouldn't, at least not with the current replacements. If in the future a new replacement requires something else you can still implement that replacement as more strict, but for the ones we have it should be more lenient

[Pablete1234]

.optional().map(DecimalFormat::new).orElse(DEFAULT_FORMAT);

[Pablete1234]

You're doing the most scope-tricks for the replacement that needs them the least. The player replacement can literally work with any scope, it shouldnt even need to do any figuring-out

[Pablete1234]

This isn't the place to write this code, make this part of the filter parser so you can parser.filter(el, "filter").respondsTo(scope).orNull()

[Pablete1234]

You can use orAllow() at the end of the filter parser to avoid the nullcheck

[Pablete1234]

scopes should be extends Filterable<?>

[Pablete1234]

As mentioned before, relegate this to a method within the replacement; let it decide what the logic for rejecting a scope should be