Extend several BSP limits

[ficool2]

Yet another pain point for mappers is some of the BSP limits, which by today's standards are quite low compared to the 2000s era when Half Life 2 was made. Particularly, the brushsides, overlays and dispinfo limits are problematic. Unfortunately, a lot of limits cannot be raised without making a new revision of the BSP format, which would break compatibility. However, this PR only bumps limits that do not require a new revision and won't break compatibility.

The PR raises the following limits:

• MAX_MAP_MODELS: 1024 -> 4096
• MAX_MAP_BRUSHES: 8192 -> 65536
• MAX_MAP_BRUSHSIDES: 65536 -> 655360 (See Note 1 below)
• MAX_MAP_ENTITIES: 8192 -> 65536
• MAX_MAP_TEXINFO: 12288 -> 32768
• MAX_MAP_TEXDATA: 2048 -> 8192
• MAX_MAP_DISPINFO: 2048 -> 16384 (See Note 2 below)
• MAX_MAP_AREAS: 256 -> 1024
• MAX_MAP_OVERLAYS: 512 -> 8192
• Detail sprites: 65535 -> unlimited (lump is variable sized)

The new value of these limits was determined by analyzing the the maximum value supported in the BSP structures, and the number adopted by other engine branches (such as CS:GO or Garry's Mod, neither of which modified the BSP format when raising these limits).

In addition, this PR also addresses an oversight in VRAD where it would add redundant map planes into the BSP and therefore potentially overflow MAX_MAP_PLANES, despite these planes only being used for radiosity calculations and never referenced in the engine.

Some of the limits could go even higher, however I opted for simplicity to avoid having to refactor a lot of code using fixed-size arrays. These values should be more than enough in practice anyway. I also checked the disk space and memory usage of the compilers, as the arrays would be now huge. It turns out that since these arrays are not initialized, they are not stored on disk, and the address space reserved for these arrays is paged out at runtime, so the impact of this is negligible.

These raised limits were tested on sample maps that went over the old limits. Using a hacked engine with the new limits, these maps were able to load in. I also tested compiling official maps such as tc_hydro, ctf_2fort... to check for potential regressions, and maps compiled with these new limits were loading successfully into an unmodified engine.

Note 1

MAX_MAP_BRUSHSIDES requires two-lines of changes in the engine. Brushside indexes are stored as 32-bit integers in the BSP, but the engine code has an internal runtime structure named cbrush_t for collision purposes, that contains the brushside index and number of sides as 16-bit unsigned shorts. These simply need to be replaced with 32-bit ints.

Note 2

MAX_MAP_DISPINFO requires one small change in the DispInfo_LoadDisplacements engine function. Displacements are built into a fixed-size array on the stack, but with the limit raised, this will cause a stack overflow. Instead, the temporary memory should be allocated on the heap with something like CUtlMemory to fix this.

[Erk-FalloutNewvegas]

this is freakin epic....