Motivation / Problem

LGTM:
if ((uint64)width * height >= (size_t)-1) {
Comparison is always false because ... * ... <= 18446744065119617024.

Considering 18446744065119617023 a valid size is well outside of the realm of sanity for any of our players computers. So, I added some more sane limits.

If someone pushes a PNG or BMP with just under size_t dimensions into BaNaNaS and anyone trying to load that heightmap, it will crash their game when trying to allocate memory. After all, make the size so you want to allocate slightly less than (size_t)-1 and that allocation will fail as there is guaranteed not enough memory, as OpenTTD will already be using more than 1 byte.

Description

Introduce a limit on the maximum side length of an heightmap image to be at most 2 times MAX_MAP_SIZE (so currently 8192), and a limit on the maximum amount of bytes to allocated for a heightmap set at 1 gigabyte.
With a 24bpp BMP that 1 GB allocation limit would result in an image with ~256 million pixels, so that limit won't be practically reached yet with 8192 maximum side lengths. However, when the maximum map size is changed, or at least the maximum size along one edge (such as in JGRPP) the size length limit becomes larger and this gets into play.

Limitations

See description; you can't load gigapixel size height maps anymore.

Checklist for review

Some things are not automated, and forgotten often. This list is a reminder for the reviewers.

• The bug fix is important enough to be backported? (label: 'backport requested')
• This PR affects the save game format? (label 'savegame upgrade')
• This PR affects the GS/AI API? (label 'needs review: Script API')
  • ai_changelog.hpp, gs_changelog.hpp need updating.
  • The compatibility wrappers (compat_*.nut) need updating.
• This PR affects the NewGRF API? (label 'needs review: NewGRF')
  • newgrf_debug_data.h may need updating.
  • PR must be added to API tracker