feat: add Nukkit platform support

[lt-name]

Overview

add Nukkit platform support

Description

Added support for the Nukkit platform, and is also compatible with the Nukkit-MOT branch.

[Timongcraft]

AFAIK translation is handled through Crowdin
And the specific languages can be downloaded here: https://github.com/IntellectualSites/Translations

[lt-name]

AFAIK translation is handled through Crowdin And the specific languages can be downloaded here: https://github.com/IntellectualSites/Translations

Removed, thanks for the reminder.

[dordsor21]

There's quite a lot of stuff that feels overly tied to specifically nukkitmot, I'm still not convinced this is necessarily the most widely-used fork looking at the repo and comparing to (e.g. powernukkitx).

There's also quite a lot of "lazy" coding, e.g. constant calls to server#getChunk rather than caching (and perhaps there are more appropriate methods to get the chunk anyway?!). Another example is the tree generation - this won't work with history and only works with three tree types. If it's an issue of no other trees supported by the server implementation then nukkit-mot wouldn't be mature enough to have an FAWE implementation yet (I also see that there is not actually a version, just MOT-SNAPSHOT. I'm also nervous that the adapters are very small and so there are a lot of random features that may fail silently, or have unintended consequences.

Lastly on my quick look-through - we do not need to use the sk89q.worldedit classpath - and some of the choices of what to put here vs fastasyncworldedit.nukkit are a bit strange.

Ultimately it falls on us to maintain the inclusion of nukkit going into the future, so we would generally want to be able to have more confidence/want to be sure that all features not yet implemented throw appropriate errors, and are clearly marked/labelled (with some explanation why) and preferably javadocs at the top of every "core" class (e.g. adapter, getblocks, etc.) describing why certain decisions have been made that offer quite a different architectural/"workflow" implementation (i.e. where we don't cache chunk, have no real concept of chunk sections, etc.) to other FAWE implementations.

I do appreciate a differentiation between mot and Nkx implementations though, and this does help to address to nukkit-mot vs powernukkitx differences, but then not having unique getblocks classes and instead offloading to the adapter (with a different design pattern (NukkitImplLoad#get) to the rest of FAWE) feels strange. It's definitely not worth closing, and I am happy to work with you to try to have support integrated, but repeating what I said earlier; since the responsibility will essentially fall on us core maintainers in the future it definitely needs to be done correctly, and following the existing design and architectural patterns & decisions in the rest of the project. Please don't feel like we do not appreciate the time and effort you'll have already put in though, I just want to be sure that it's done right for us as well

[lt-name]

There's quite a lot of stuff that feels overly tied to specifically nukkitmot, I'm still not convinced this is necessarily the most widely-used fork looking at the repo and comparing to (e.g. powernukkitx).

There's also quite a lot of "lazy" coding, e.g. constant calls to server#getChunk rather than caching (and perhaps there are more appropriate methods to get the chunk anyway?!). Another example is the tree generation - this won't work with history and only works with three tree types. If it's an issue of no other trees supported by the server implementation then nukkit-mot wouldn't be mature enough to have an FAWE implementation yet (I also see that there is not actually a version, just MOT-SNAPSHOT. I'm also nervous that the adapters are very small and so there are a lot of random features that may fail silently, or have unintended consequences.

Lastly on my quick look-through - we do not need to use the sk89q.worldedit classpath - and some of the choices of what to put here vs fastasyncworldedit.nukkit are a bit strange.

Ultimately it falls on us to maintain the inclusion of nukkit going into the future, so we would generally want to be able to have more confidence/want to be sure that all features not yet implemented throw appropriate errors, and are clearly marked/labelled (with some explanation why) and preferably javadocs at the top of every "core" class (e.g. adapter, getblocks, etc.) describing why certain decisions have been made that offer quite a different architectural/"workflow" implementation (i.e. where we don't cache chunk, have no real concept of chunk sections, etc.) to other FAWE implementations.

I do appreciate a differentiation between mot and Nkx implementations though, and this does help to address to nukkit-mot vs powernukkitx differences, but then not having unique getblocks classes and instead offloading to the adapter (with a different design pattern (NukkitImplLoad#get) to the rest of FAWE) feels strange. It's definitely not worth closing, and I am happy to work with you to try to have support integrated, but repeating what I said earlier; since the responsibility will essentially fall on us core maintainers in the future it definitely needs to be done correctly, and following the existing design and architectural patterns & decisions in the rest of the project. Please don't feel like we do not appreciate the time and effort you'll have already put in though, I just want to be sure that it's done right for us as well

Thank you for your review suggestions, and I apologize for not checking GitHub over the past few days and not being able to reply in time.
During the development of this Nukkit compatibility implementation, I heavily referenced the Bukkit implementation with the help of AI, which is why there are many classpaths similar to those used by Bukkit. When I have time, I will start working on optimizing these issues. If possible, I will also try to introduce PNX support so as to achieve as broad compatibility as possible across Nukkit forks.