[q3map2] allow to set arbitrary default light subdivision value

Q3Map2 documentation says about -fast switch*:

Enables light envelopes for area (shader) lights. This includes radiosity lights. Results in a much quicker -light compiles, but darkens all enveloped light sources considerably—this can be compensated for easily by raising your surfacelight values. Do not be confused by the "fast" nomenclature... -fast is perfectly suitable for "final" compiles.

We can also read about q3map_lightSubdivide*:

Used on surface lights (see q3map_surfacelight). Chops up the surface into smaller polygons for more uniform lighting. It defaults to 120 game units, but can be made larger or smaller as needed (for light surfaces at the bottom of cracks, for example). This can be a dominant factor in processing time for Q3Map2 lighting. Can have an increasingly "darker" effect when used with -fast. Compensate by raising the surface light value. For sky shaders, use q3map_skylight instead (see Appendix I: Light Emitting Shaders).

So, if -fast is suitable for “final” compiles, it introduces issues while used in combination with subdivisions. That leads to some big headaches. Once you activate the -fast switches, the amount of emitted light of a light emitted shader is the result of a magic operation between the q3map_surfacelight amount and the q3map_lightSubdivide number.

While q3map_lightSubdivide is reduced (increasing quality of casted shadows), q3map_surfacelight must be increased to compensate, and relations between these two values looks more tied to magic than to something rational. So, since reducing subdivision value increase both quality and compile time, it means the mapper must write as much versions of the shaders as the mapper has map compilation profile. It makes lightmap testing impossible: no one test done with quick compilations option (like large subdivision) is able to tell something about result in final build (with small subdivisions).

The only way to have a fast test build with default light emitting shader subdivision that looks almost reliably like a final release build with smaller light subdivision is to compile the final build not using the -fast mode.

It means, once a mapper use both -fast switch and customized at least one light emitting shader subdivision, the mapper can't change any option without breaking the lighting, it means the mapper can't speed up the build just to check some experimentations without breaking the lighting. Once the magic combination “-fast, lightSubdivide, compile time” is done, the mapper is not able to change one of these three variables without breaking the lighting. If it happens, the mapper falls again in the hell of that trial&error process involving dark magic that can bite himself at any time, enslaving his soul for eternity for sure.

The current workaround is to add this kind of stuff in every light emitting shader:

// q3map_lightSubdivide 100
// q3map_noFast

Keeping this stuff disabled for fast build, Enabling it for final build. Of course it's not a good solution, it means the source is not stable, and the workflow is not compatible with source version control system.

So, the idea is to switch both noFast and lightSubdivide at compile time, onas q3map2 command line switches.

To switch on noFast, it's enough to just not pass the -fast switch to q3map2. There was no option to change lightSubdivide value.

That's the motivation of this MR.

People can do faster preview build using q3map2 -nofast switch (the emitted light amount will be the one expected, but the shadows will be very poor as expected), then people can do final build using both -nofast switch and -lightsubdiv switch (the emitted light amount will be roughly the one expected, but the shadows will be nice).