Resolves #168 : Direction*Vector now returns the rotated Vector,and vec...

...tors can be rotated with DIRECTION suffix.

For Example:
```
// Gets the world coords vector corresponding to
// the geo-coords vector: north=20,west=10,up=50
SET MyVec to V(20,10,50).
SET MyRotatedVec TO UP * MyVec.

// The new Vector :DIRECTION suffix would allow you to get the old "*" result if you want it:
SET oldStyleMultResult TO MyRotatedVec:DIRECTION.

// Gets the world coords vector corresponding to a position in
// space that is 30 meters in front of the target ship's CoM in
// the direction the target ship is pointing:
SET PosAheadOfTarget TO TARGET:POSITION + ( TARGET:FACING * V(0,0,30) ).

// You can now get the Direction of a Vector with the :DIRECTION suffix,
// as the analogous inverse to Direction's :VECTOR suffix:
SET surfDir to SHIP:VELOCITY:SURFACE:DIRECTION. // an alternate way to get surface prograde dir.

// The Vector's new :DIRECTION suffix is also settable.
// Much like setting a vector's :MAG will keep its orientation but give a new length,
// setting a the Vector's :DIRECTION will keep its length but give it a new orientation.
SET MyVec to V(3,4,0).  // vector's magnitude is sqrt(3^2 + 4^2) = 5
SET MyVec:DIRECTION TO UP. // magnitude is still 5 but now points at navball UP.
```

Well, of course.  I assumed that would be part of what you want to add in your refactoring of the GetSuffx/SetSuffix system.  Presumably the datatype we invent to store "what is true about this suffix?" would include a field for "what is the type this suffix expects?".  The icky part is suffixes that expect multiple parts that we don't currently inherit from each other (For example a suffix might expect either a Direction or a Vector).