feat: Add 26.3-snapshot-2 config and patches

[Dario-Maselli]

NOTE: This PR needs the PR from SrgUtils (MinecraftForge/SrgUtils#25) to be merged before this can be merged as there is a temporary fix to build the SrgUtils locally with the updated snapshots.

This pull request introduces several improvements and fixes across the build configuration and client patch files, primarily to update dependencies, add support for a new pre-release version (26.3-snapshot-2), and resolve various type and logging issues in the codebase.

Dependency and Build System Updates:

• Updated the net.minecraftforge:srgutils dependency from version 0.6.2 to 0.6.6 in buildSrc/build.gradle and added dependency substitution to use a local SrgUtils project in both buildSrc/settings.gradle and settings.gradle. [1] [2] [3]
• Added a new configuration and dependency for mappingToyClasspath in update.gradle, and updated the runMappingToy task to use this configuration. [1] [2]

New Version Support:

• Added configuration and support files for versions/pre/26/26.3-snapshot-2, including a new config.json and a Start.java entrypoint for launching the client. [1] [2]

Client Patch Fixes and Improvements:

Type Safety and Type Casting:

• Fixed or added explicit type casts in several patch files to resolve type inference and generic issues, such as in OptionInstance.java, PresetFlatWorldScreen.java, WorldCreationUiState.java, BookViewScreen.java, ChatComponent.java, and ModelFeatureRenderer.java. [1] [2] [3] [4] [5] [6]
• Improved type handling in EntityRenderDispatcher.java by wrapping the switch result in an explicit cast.
• Clarified lambda parameter types in FontSet.java to avoid ambiguity.
• Simplified a generic method call in VariantSelector.java by removing an unnecessary cast.

Logging and Exception Handling:

• Fixed incorrect variable references in logging statements and exception handling in PackSelectionScreen.java and CreateWorldScreen.java. [1] [2]

Code Structure and Logic:

• Refactored switch/case blocks in LevelEventHandler.java to use explicit code blocks for certain cases, improving readability and correctness.
• Refactored variable usage in BeaconRenderer.java to reduce redundancy and clarify variable scope.

(References: [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]

[LexManos]

This very much appears to be a AI pass of doing the update.
Which isn't bad, it just makes your description filled with useless information.
You're describing what happens in the patch files (which I wrote for older versions). But are completely wrong about WHY the patches exist. They are there to fix decompile artifacts, allowing the code to compile/run. That's it, nothing to do with avoiding ambiguity or reduce redundancy and clarify variable scope

The main issue is that the changes haven't been tested, compiling the game fails.

> Task :26.3-snapshot-2:testCompileClientHotSpot25
\versions\pre\26\26.3-snapshot-2\projects\client\src\main\java\net\minecraft\client\resources\palette\PalettedTextureManager.java:57: error: incompatible types: invalid method reference
            .removalListener(notification -> ((Optional)notification.getValue()).ifPresent(PalettedTextureManager.BaseTexture::close))
                                                                                           ^
    method close in record BaseTexture cannot be applied to given types
      required: no arguments
      found:    Object
      reason: actual and formal argument lists differ in length
\versions\pre\26\26.3-snapshot-2\projects\shared\net\minecraft\world\level\storage\loot\LootContextArg.java:28: error: incompatible types: LootContextArg is not a functional interface
        return () -> contextParam;
               ^
    multiple non-overriding abstract methods found in interface LootContextArg

I've pulled in the SRGUtils PR, so you can remove all those changes.
Also, snapshots go into the snapshots directory, pre releases (now called release candidates) go in the pre directory.

Make sure that you run the testJdks task to run the needed tests. As well as test compiling using Eclipse itself. As their compiler has some differences with generics. In this case, there doesn't appear to be any, just those two compile errors above.