Improve map grid size handling, fix fullscreen map cutting off

[leumasme]

First commit makes the grid size dynamic instead of a constant 5x5. Fixes #34

Other 2 commits clean things up and make the grid able to be non-square, e.g. 5 tiles in width and 3 tiles in height.
This should reduce the amount of work done. when playing in fullscreen on a 1920x1080 screen, only 3x5=15 tiles are used instead of 5x5=25.
I have not benchmarked the actual impact of this as I'm not sure how to do this here.
These also create changes in public functions, which may count as a breaking (major version increase) change, depending on your versioning.
If these other things are unwanted, I can drop the commits.

All changes are tested ingame. Proper review and testing would still be appreciated as i find this codebase a bit confusing.

[CLAassistant]

All committers have signed the CLA.

[AnrDaemon]

Leave the API as is, use wrappers to clamp the inputs to a new scheme.

[leumasme]

The input will get overwritten anyway when the gridSize gets recalculated next (I think the caller has no useful purpose for passing a gridSize here).
I could leave a constructor that accepts a gridSize but just discards it to call the normal constructor for API compatability (As added initially, removed in second commit)
If that doesn't satisfy, I don't know what you mean; please clarify.

[AnrDaemon]

I did mean to keep public API breakage to an absolute minimum. You never know, where it would be called, and you can't possibly fix every dependent code you don't control.

[mysticdrew]

If it works fine in gtnh pack it can be removed

[leumasme]

Confirmed compatability with a recent GTNH nightly.
Also confirmed compatability with VisualProspecting overlays.
Compatability with TCNodeTracker overlays couldn't be tested because TCNodeTracker appears to be fully broken in nightly.

I can still restore api compatability if it's preferred (already have that stashed anyway), although methods such as public setGridSize would have to be empty dummy methods.

[mysticdrew]

please update the doc/changelog.html
you can replace the current line item in there.

This is very similar, almost identical in places to the changes I did to fix this in 1.12.2, did you decompile that code to look? It's fine if you did, just curious.

Other than the change log update, looks great, thanks a lot.

[leumasme]

did you decompile that code to look?

I did take a look at the recalculation logic, but I think that was the only sensible way to implement this anyway. Looks like later releases still use a square tile size though(?); I wonder what the performance impact of that is.
As a note, the formula for the required tile size was also slightly suboptimal in the version I looked at;
ceil(windowsize / tilesize) + 1 may calculate a number that's larger than required (e.g. 4 for 1080p -> 5 tiles to make it odd, even though only 3 are required)
ceil(windowsize / tilesize + 0.5) is more accurate to represent the possibility panning away from the center by up to half a tile, and correctly yields 3 for 1080p screen height, 512 tile size

[mysticdrew]

@leumasme see #36

[leumasme]

Looks like minimap calculation is coming up with needing only 1x1 tiles? Maybe just let it be minimum 3x3, think that should fix it (not 100% sure). Alternatively change formula to be ceil(cells)+1 instead of ceil(cells+0.5), the exact thing I wrote about before... But that may result in some unnecessary work done on specific resolutions.
Sadly I'm not home for the next 4 days so I can't do it myself, sorry for the bug.

[mysticdrew]

I am also going to be very busy until next week. Users can use the old version until a fix can be completed.