In PHP 8.4, the type of `PHP_DEBUG` changes from `int` to `bool`.
See [PHP.Watch: PHP 8.4: `PHP_ZTS` and `PHP_DEBUG` constant value type changed from `int` to `bool`](https://php.watch/versions/8.4/PHP_ZTS-PHP_DEBUG-const-type-change).
This changes the constants to `ZEND_DEBUG_BUILD`, which contains the same value but as a `bool` across all PHP versions.
closes#6222
this is supported since libdeflate 1.15 and ext-libdeflate 0.2.0.
Everyone should be using these versions by now anyway, and if they aren't, they should update.
libdeflate's level 0 compression is over 20 times faster than zlib, so this is a nice performance improvement.
Since task execution depends on tasks executing sequentially on a particular worker in some cases (e.g. PopulationTask must be preceded by GeneratorRegisterTask), it doesn't make sense to continue task execution if an error occurs.
Moreover, a task crashing may render the whole server unstable, as it leaves the server in an undefined state. This is the same kind of problem we fixed with scheduled tasks in PM3.
In versions past, pthreads was unreliable enough that random tasks would crash without an obvious reason, forcing us to accommodate this. I still don't know the origin or frequency of said issues, but I think it's time to rip the band-aid off and solve these problems for real.
the only use for this class is to facilitate random runtime plugin loading, and it's not complete even for that purpose.
Since nothing but PM uses pocketmine/classloader anyway, it doesn't make sense to have it outside the core. As with LogPthreads, it's just adding more maintenance work.
on a modern installation, the plugins folder does not need to be writable by the server. Perhaps DevTools should be checking this for /genplugin, but it's not required otherwise.
I've stuck to only doing this in the places where I'm sure we should never get false back. Other places I'm less sure of (and I found more bugs along the way).
Sacrifice dynamic composer autoloader path to do this, because we don't
need it anyway - it was a misconceived feature from the days when I used
the same workspace for PM3 and PM4 both.
this avoids needing to call Terminal::init() before starting a MainLogger. Since it inits the formatting codes anyway when log messages are first recorded, it shouldn't be necessary to pre-initialize it.
