Fix a possibly-undefined variable warning.

(Noticed by /dev/humancontroller.)
fix up the grammar etc. in various printed messages
remove a load of unwanted trailing newline characters (from arguments to Error()ish calls, etc.)
fix the spelling of a bunch of identifiers
allow negative values for initial velocity and acceleration magnitudes of particles

negative velocity/acceleration magnitudes can be used to create fancy particle flight paths when normal-based velocities/accelerations are used
allow particles of child particle systems to be launched with (dynamic) normals

currently, particle systems attached to particles do not have valid normal vectors. such particle systems are not able to launch or displace new particles in a direction based on normal vectors (error messages are printed when particles with normal-based particle trajectories are created).

having a normal vector for a mobile particle system can be useful: one might want to displace physically large particles away from a wall, if the particle system is touching that wall (but do not apply displacement if the system is flying). in this case, a normal vector can be defined by the map surface for the wall. one can also create fancy effects with the use of such normal vectors.

new particle script constructs (in particle blocks):
  {velocityType | accelerationType} {last_normal | opportunistic_normal}

the base vector in case of opportunistic_normal is (0,0,0) if the particle is flying, and is a surface normal vector if the particle is in/on a map surface. the base vector in case of last_normal is always a valid direction, though sometimes an arbitrary one (the up direction). in both cases, the initial value of the last/opportunistic normal vector is propagated from the parent particle.

the last/opportunistic vector is a new particle system variable, and the original normal vector is not touched, so this change retains backward-compatibility.
do not treat a clipmask of 0 as MASK_DEADSOLID in some cases

remove the clipmask == 0 special cases from G_TestEntityPosition() and G_Physics(). when spawning corpses, set their clipmask to MASK_DEADSOLID instead of 0.
always spawn corpses where the model coincides with the ending state of the death animation
never set groundEntityNum to -1, or compare groundEntityNum to -1; use ENTITYNUM_NONE instead
fix G_FindCreep(), after exposing a bug by fixing groundEntityNum

aliens were creep-healing while in air
allow configurable teleporter ejection speed via the "speed" spawn variable

this is primarily to allow maps to specify no player-spitting after teleportation
remove the useless "do not allow using" spawnflag from trigger_hurt entities

by ==Troy==
fix the trigger linkage after trap_SetBrushModel(), for trigger_hurt and trigger_heal entities

by ==Troy==
remove a bunch of superfluous va() calls
remove the ineffective ``#if CS_MAX > MAX_CONFIGSTRINGS'' check, as CS_MAX is no longer a macro constant
high-precision buildable placement

currently, it's possible to initiate the construction of power/creep-bound buildables by trying to place them at the very edge of the power/creep zone. this was wrongly believed to be caused by floating point imprecision.

when buildables are built, they are placed a bit above the ground, and then "gently" nudged down for whatever reason. however, due to the bouncy physics of the buildables, the buildables bounce up even higher, and stop up there for whatever reason.

from this follows a minimal tutorial on how to easily build unpowered telenodes: build a telenode near the upper edge of the power zone, so that the telenode becomes out of range when it "jumps up" (ie., build in a room above the repeater).

perhaps the nudging was supposed to align the buildable's bottom with the floor, while guaranteeing that buildables don't meld into the ground. however, this displace-and-nudge method should not be required to avoid objects "melding", due to the engine's surface clipping epsilons.

taking the above in mind, i have modified the code to precisely place the buildable at the end of the primary trace, and to keep the buildable stationed there. G_CanBuild() now offers to return the number of the ground entity on which the buildable was placed; the buildable placement functions pass that number to G_Build(). in G_Build(), it is assumed that if a ground entity is specified (ie., if the number is not ENTITYNUM_NONE), then the buildable can stably rest on the surface, and so is stationed there. buildable displacement is also removed, as it is deemed unnecessary.

the most obvious additional benefit of the precise buildable placement is that it's likely to cease all cases of alien buildables falling off the ceiling due to some amount of imprecision. furthermore, the withdrawal of buildable displacement during layout loading can decrease the number of cases of saved buildables failing to load due to start-solid errors.