Use floats in combat system again to fix desync problems

I had a deep look at pull request #2242 by @JamesDunne as we suspected this introduced problems. It is massive bunch of changes.

My guess is that the change of data types in `Combat.cs` from float2 to new int derivatives is crucial as it effects `Weapon.cs` in one case. I therefore reverted the PVecInt data types of the *Barrel* functions back, but used the new PVecFloat instead. I think this should make sense. Did not care about everything in the Effects folder. Just modified it to compile again. This commit also removes some conditional compilation left-over junk.

I prepared a test build https://www.dropbox.com/s/5uqpybr1ti210o5/OpenRA-pvecfloat-combat-20130205.zip which is a MonoDevelop compilation with some Windows DLLs so it works out of the box for volunteer testers. We did some quick test games with multiple players, different OS and lot's of units and combat: ~10 games without desync. We have no proper test-case for it, but it should have triggered a sync blame exception when playing excessively. This should fix the common mysterious late-game de-sync-crash introduced in mid 2012 that is hard to reproduce:

* #2607
* #2504
* #2505
* #2478
* #2357
* #2321
* #2055

It does not fix the reproducible shroud-fog-cheat-missile problem #2661and the game will crash when neutral has gap generators #2664 so I think those are unrelated.