Allow Quake II deluxemapping and HDR output

[Toodles2You]

I refactored the checks in such a way that it won't write RGB lighting, since that's a little redundant. :)

As for engine support: I've implemented a little fix for FTEQW, so it'll correctly load the HDR lightmaps from Quake II BSPs. (fte-team/fteqw/pull/355)

[ericwa]

There's one thing I'll need to fix first: bsp->dlightdata.size() is the number of bytes, so if !has_rgb_lightmap it's the number of light samples, and if has_rgb_lightmap it's the number of samples * 3.

The code that was previously in the if (!bsp->loadversion->game->has_rgb_lightmap) { block assumes that bsp->dlightdata.size() is the number of samples, so it's going to need adjustments to work with Q2 (same with WriteLuxFile and WriteLitFile) - currently in this PR, if you request these new formats on a Q2 map, I think they're going to be 3x as big as they should.

---

@Paril does this look OK with you? In summary, the PR enables the following on Q2 bsp's, which we previously disallowed:

• BSPX lump "LIGHTING_E5BGR9" (activated with -bspxhdr flag)
• BSPX lump "LIGHTINGDIR" (activated with -bspxlux flag)
• .lit file with LIT_VERSION_E5BGR9 (activated with -hdr flag) - but not regular .lit which would be completely pointless
• .lux file (activated with -lux flag)

I think these should integrate fine with DECOUPLED_LM.

I'm wondering if we should limit it to the two BSPX ones, since they are identical to the .lit HDR and .lux files, just to avoid an explosion of new formats.

[ericwa]

I'm wondering if we should limit it to the two BSPX ones, since they are identical to the .lit HDR and .lux files, just to avoid an explosion of new formats.

Let's keep all 4 formats.

Merged in 679b132 + fixed the lit/bspx lump size in 7c1f8fd.
Some cleanup in 0418453 9658726 578ab89 2729dd1