Prevent custom tick threads from blocking shutdown

[Txaverria]

What changed

• Use a dedicated ThreadFactory for custom tick schedulers.
• Name workers TIL-CustomTick-N to make them identifiable in diagnostics.
• Mark the workers as daemon threads so process-lifetime custom ticks cannot keep the JVM alive after shutdown.

The scheduling behavior and one-executor-per-custom-tick design are otherwise unchanged.

Root cause

CustomTick.addCustomTick creates a scheduled executor for each registered custom tick and discards the executor handle. The default executor thread factory creates non-daemon workers, so an idle worker remains alive after the Minecraft server finishes stopping and prevents the JVM from exiting.

This was reproduced with Music Triggers 7.0.4 on a Minecraft 1.20.1 / Forge 47.4.0 dedicated server. AllTheLeaks traced the stuck pool-4-thread-1 creation to:

CustomTick.addCustomTick
CustomTick.addCustomTickTPS
MTCommonEvents.init

Impact

Dedicated servers using a custom tick can now exit normally after saving. Daemonizing these process-lifetime workers also avoids introducing server lifecycle cleanup that could stop custom ticks permanently when an integrated server is closed and another world is opened in the same client process.

Validation

• :api:compileJava passes.
• The patched class remains Java 8 bytecode, matching the released class.
• Packaged and tested against The Impossible Library 0.4.7 with Music Triggers 7.0.4.
• A client joined the Forge 47.4.0 dedicated server successfully.
• Before the change, every stop left Java running and AllTheLeaks reported the non-daemon executor.
• After the change, the server saved all dimensions and the JVM exited immediately with no stuck-thread warning.

The repository-wide assemble task was also attempted, but upstream's unrelated Minecraft 1.18 Unimined MCPConfig rename step exited during remapping before task execution completed.

[Txaverria]

Doing this 1.20.1 update should resolve this issue:
TheComputerizer/Music-Triggers#238