Give greater control over projectile movement

Give greater .ini control over projectile trajectories/re-implement dummied-out projectile behaviour tags (Dropping, Level, Floater, etc).

* For one, voxel projectiles are hard-coded to drop down initially. This prevents voxel-based projectiles to be fired down cliffs, from hovering units, or with CourseLockDuration. This hard-coded feature should be restored to be customizable through the Vertical=y/n tag. Potentially it could be made even more customizable through an InitialVector=n tag, where n is an angle, like FireAngle.
* The "Dropping" projectile tag has been inoperational, although parsed, since TS inclusive. What it is *supposed* to do is to attach a parachute (and hence regulate FallSpeed) to a projetile. What is actually *does* since TS is to instantly 'kill' the projectile upon being created. The "instant-detonation" makes for interesting features though, so this effect should be kept in the code somehow, perhaps by allowing MaxEC for projectiles, or restoring the ProjectileRange feature from Firestorm. These two tags would allow instant-detonation, but also more customizable detonation distances from the firer.
* The "Level" tag creates a projectile which flies straight, but will be tied to travelling on water. The enforced terrain part should be removed from this tag, which would make it create a regular straight-fire projectile.
* The "Floater" tag has no discernible effect in either TS or RA2, but according to the commentary, its intended effect was pretty much like the "Level" tag, except that it is set on weapons instead of projectiles.
* The "Vertical" tag is new in RA2, but has no positive effect apparently - the Kirov's projectile is hardcoded (via the voxel's initial vector described above) to behave the way it does. This tag should be made useful by making it customize the initial vector for both voxel and SHP projectiles.
* Maybe some more exotic tags, such as BallisticHeilightHeight (ceiling height of the ballistic arc), AscentRate, DescentRate, etc would provide even greater degree of flexibility for customizing trajectories. Looking at the behaviour settings for spawned missiles might provide inspiration in this respect.

This could obviously be tied in with the often-requested straight-fire projectile feature.

Some smaller issues:
* Bouncy/Elasticity do not work in RA2/YR
* Inaccurate/FlakScatter do not work in RA2/YR