Add per-arena min/max spawnpoint distance settings.

Introduces two new settings for controlling how far away from or close
to a spawnpoint players must be in order for the spawnpoint to be valid
when spawning monsters.

This is a pretty big one. In ancient times, MobArena had no limit on how
close players had to be to spawnpoints for them to be valid. The result
was mobs spawning too far away from the players, frozen in place until
their target approached them or until another player attacked them. This
was clearly undesirable, so the 15-block max distance was introduced to
solve this problem. And it worked, hurray!

In the meantime, it also imposed a really cumbersome limitation on all
arena designs, since aesthetically (or strategically) placed spawnpoints
were seldom sufficient, and server owners have been needing to litter
their arena floors with spawnpoints to avoid warnings and to get their
expected monster behavior.

Modern versions of Minecraft no longer exhibit that "frozen in place"
behavior the hardcoded max distance set out to solve, and server owners
have been asking for configurability on this front for years. With this
commit, that distance is now per-arena configurable. The change has no
real impact on the performance of the plugin. It's worth noting that we
don't modify the pathfinding attribute `generic.followRange`. We might
want to revisit this in a future commit, but since it can _definitely_
affect performance, we should have some actual servers run a test build
with it before jumping on that wagon.

Having many spawnpoints might still be preferable to some, but it comes
with another problem of players standing right on top of a spawnpoint
when a monster spawns. To combat this, an additional setting to control
the _minimum_ distance that _all_ players must be from the spawnpoint
for it to be valid is introduced as well. This means it is possible to
have lots of spawnpoints for a less predictable session, but without the
risk of being instantly attacked when a new wave spawns. This change has
a theoretical performance impact on the plugin, because it's a lot more
brute force without the early returns of the old algorithm. However, if
the setting is left at 0, the old algorithm is used.

The only real downside to these changes is that it's more code and more
settings to maintain. It doesn't improve on the clusterfuck that is the
arena settings in the config-file - we're just making things worse. I do
think it's worth having, though, since the bigger revamps on the drawing
board are at best months away, and at worst, they'll never happen. When
or if the time comes, it's probably better to rethink certain aspects of
the plugin instead of trying to convert everything gracefully.

Closes #412

changelog.md

@@ -14,6 +14,8 @@ These changes will (most likely) be included in the next version.
 ### Added
 - MobArena now properly supports Vault economy providers registered after MobArena has started. This should make it possible to use custom economy providers that aren't built into Vault, such as those created with Denizen.
 - New wave rewards section `tiers` allows for _non-stacking_ reward tiers for beating certain waves. This allows for configuring reward sets that get "upgraded" as the waves progress, e.g. by granting a full leather armor set for beating wave 15, but beating wave 20 _replaces_ that leather armor set with an iron armor set.
+- New per-arena setting `spawnpoint-max-distance` can be used to tweak how close to any player a given spawnpoint must be to be considered valid when spawning monsters. This should help reduce the amount of spawnpoints required, especially for larger arenas.
+- New per-arena setting `spawnpoint-min-distance` can be used to tweak how far away from all players a given spawnpoint must be to be considered valid when spawning monsters. This should help prevent monsters from spawning directly on top of players.
 
 ### Changed
 - Recurrent waves can now be randomized. If two or more recurrent waves clash on wave number, frequency, _and_ priority, MobArena will now randomly pick between them. This should make it easier to create more varied and interesting wave setups without having to resort to only massively randomized default waves.