Add initial Folia support

[Saros-6585]

Problem

Briefly, support Folia.

This discussion seems to have already started around 2023, but there has been no progress because no one has done the right thing. It might have been difficult to support Spigot at the same time, but now Skript is Paper plugin, so we can support Folia with very small changes. Folia's stable build release is also quite a while old, so I think it's time to do.

As I said before, the change is simple. Skript no longer supports Spigot, we can change all Bukkit Scheduler to Paper Scheduler.

Solution

• Deprecate ch.njol.skript.util.Task
• Remove Bukkit schedulers
• New Centralized paper scheduler management class: org.skriptlang.skript.util.Scheduler
  • it replace deprecated/removed Task class and Bukkit schedulers

so now Task class is no longer in use, change to Scheduler class.
but SQLStorage class is an exception. I think it's up to Improving Variable Storages PR.

Testing Completed

quickTest passed, but manual testing isn't yet. I would like to manual test this after an appropriate code review has been conducted.

Supporting Information

I'm on SkriptLang, skUnity discord server too, if you have anything you want to talk about this PR, you can do it through this PR, but if you want to talk on Discord, please mention saros.6585 :)

and I referred to 'SkriptFolia' project for edit EffDelay. Thank you Shane!

---

Completes: #5645
Related: #5645
AI assistance: GPT-5.6-Sol, to find where to use the existing Task class and Bukkit schedulers.

[sovdeeth]

You should manually test this because I do not think this is at all safe. The changes to use paper scheduling is fine and great, but I believe there needs to be many more guardrails than a simple change to wait. For example, changing blocks in 2 separate regions at one I do not think is supported in Folia, and skript doesn't really have any handling for that. Waiting on a block and then trying to interact with an entity is likely also prone to issues. This needs a lot of testing and a serious attempt at making it safer for users to have Skript officially support it.

It is likely better to have this PR focus on updating the scheduling in Skript, and deal with official support, delay implementation, and proper thread safety in later PRs.

[Saros-6585]

Thank you for the quick review. I certainly didn't expect this to be a simple task. While the extent of code changes might be smaller compared to supporting Spigot, that doesn't mean the likelihood of issues arising from these changes is significantly lower.

I'm glad to hear that you found the updated code style acceptable. The reason I opened this PR after only running quickTest was that I wanted to get code reviews first. I plan to manually test this build on a Folia test server from time to time. However, as this is my first contribution to the Skript, there might be crucial aspects I overlook. I'd really appreciate it if you could point those out too. :)

Also, splitting this PR into two phases is definitely worth considering, but for now, I'd like to do my best with this PR to get Folia support ready—at least to the point where it can enter a public testing phase. Of course, if things don't work out, I'll pivot to the direction you suggested haha.

Thanks again, I'll keep pushing this PR forward as far as I can.

[AnOwlBe]

you should consider running JUnitQuick beforehand locally next time

[sovdeeth]

Also, splitting this PR into two phases is definitely worth considering, but for now, I'd like to do my best with this PR to get Folia support ready—at least to the point where it can enter a public testing phase. Of course, if things don't work out, I'll pivot to the direction you suggested haha.

I appreciate the desire but it's going to be a much bigger process, and we can't in good conscience claim to officially support until we can be confident Skript code is safe and functional on Folia, even if users don't code in a folia-specific manner. So having this PR claim official support is going to be premature, but it will be a good stepping stone to get started!

I don't want this PR to get bogged down in tons of difficult edge cases and such that will no doubt arise, because it's better to get the low hanging fruit in while we can, so it can be built upon step by step!