findExecutableOnPath, for the new webp feature, can cause NPE in some environments

Issue Description:

Commit 460e6f981 of 2020-10-25 adds a new method findExecutableOnPath that calls System.getenv("PATH").split .... In a Multicraft environment, java seems to get called without PATH being defined, probably for security reasons. This results in System.getenv("PATH") returning null, and the method throwing a NPE, preventing dynmap initialization.

Solution: make the method return null if System.getenv("PATH") returns null.

[X] I have looked at all other issues and this is not a duplicate
[X] I have been able to replicate this

[gbl]

Don’t be so hard on the author, he has been supporting dynmap for many years, even added support for Forge and Fabric recently, and dedicated a lot of time into the project - time he isn’t getting paid for. None of us knows how the pandemic affects him or his family, and if he has other priorities right now, then noone has the right to critizise this.

Also, releasing a piece of software correctly is much more work than just uploading it; you need to run tests, upload to all distribution sites, update descriptions, update version info, and even if some of this can be automated, you still need to do a lot of work manually.

I’m convinced that, when once one development speeds up again, this fix will quickly make it into the official distribution. Until then, enjoy the advantage of open source which means people can fix stuff themselves if the original author won’t, for whichever reason.

[gbl]

I didn’t intend to publish my version, because, as I said, software from unknown origins isn’t what people should run. But, it’s been over two weeks without this bug being resolved, so, here’s my release:

https://github.com/gbl/dynmap/releases/tag/fix_path_problem

Note that I wrote that before dynmap officially supported 1.16.4, so, it was forked from an older version. But it has been in production on two different servers for two weeks now, so it should work for you as well.