Optimize nearest structure border iteration

[MartijnMuijsers]

Getting the nearest generated structure calls ChunkGenerator.getNearestGeneratedStructure, which contains a nested set of loops that iterate over all chunks at a specific chessboard distance. It does this by iterating over the entire square of chunks within that distance, and checking if the coordinates are at exactly the right distance to be on the border.

This patch optimizes the iteration by only iterating over the border chunks. This evaluated chunks are the same, and in the same order, as before, to ensure that the returned found structure (which may for example be a buried treasure that will be marked on a treasure map) is the same as in vanilla.

Since the radius may be quite large (50 for buried treasure maps in chests, 100 for cartographer treasure maps, or any arbitrary value for plugin calls or data pack functions) this effect is noticeable.
For example, for a cartographer treasure map, where the call to ChunkGenerator.getNearestGeneratedStructure is made from ChunkGenerator.findNearestMapStructure with an increasing radius, this effect can cause $\sum_\limits{i=1}^{100} (2i+1)^2-8i = 1,333,300$ unnecessary loop iterations, of which the bookkeeping can easily take half a millisecond, which is 1/100th of the main thread tick time already, spent just on pointless variable incrementing.

[kennytv]

Thanks!