Merge remote-tracking branch 'dunparatu/console-linewrap-issues'
First pass at getting vector drawing functionality into kOS
Vector Rendering done.  I squashed about 15 commits together in my local repo into this one.

Very similar to the design of the original issue I wrote, but a bit
different as I saw things didn't work like I'd expected they would
origingally:

This commit message is long because in it I describe the design, and why it required some
changes to deeper kOS objects like UpdateHandler and Variable.

```
SYNTAX:
  set anArrow to VECDRAW().
  set anArrow:START to V(0,0,0).  // origin of vector tail.  default=v(0,0,0), ship's center.
  set anArrow:VEC to V(a,b,c). // any vector will work here.  default=null.
  set anArrow:COLOR to RGB(1,0,0). // color name, RGB() or RGBA() tuple.  default=RGB(1,1,1).
  set anArrow:LABEL to "string".  // shows text label on vector.  default="".
  set anArrow:SCALE to 5.0.  // how many meters per vector unit to draw in space. default=1.0
  set anArrow:SHOW to true.  // nothing appears until you do this.  can be toggled as desired. default=false.
  set anArrow:WIDTH to 0. // if 0, kOS dyanmically picks width.  If >0, you pick width.  default=0.

Note, VECTOR can be used as a synonym for VEC, and COLOUR for COLOR.

  // Parameters may be given all at once like so:
  set anArrow to VECDRAWARGS( a, b, c, d, e, f).
     where
       a = :START
       b = :VEC
       c = :COLOR
       d = :LABEL
       e = :SCALE
       f = :SHOW
```
A vecdraw will draw a vector on the screen visually in 3-D space, and remain there
until you explicitly remove it or make the variables holding it go away.  The vector
drawings are meant primarily as a debugging tool, but could be used to show things
to a user running the script if you wish.

Each VECDRAW object in kOS is a VectorRenderer object in C#.

The ship's coordinates in 3-D space keep moving.  After coming out of time warp,
the ship's center of mass is at (0,0,0), but it starts drifting after that.  KSP
only guarantees that the origin will be *near* the ship, not directly on it.
Therefore to keep the vector drawings moving with the ship requires constantly
changing their coordinates to match the ship.

This is handled using an Update().  Each VectorRenderer is an IUpdateObserver.
It inserts itself into the UpdateHandler's update queue when it becomes visible
with the SHOW suffix, and it removes itself from the UpdateHandler's update queue
when it's made invisible with the SHOW suffix.

At first this created a problem because this means that when a user does this:
```
set vd to vecdrawargs(v(0,0,0),v(5,0,0),red,"5x",1,true).
set vd to vecdrawargs(v(0,0,0),v(0,5,0),red,"5y",1,true).
```
The first vecdraw will remain on the screen and be impossible to
ever get rid of from the kOS script.  If the command ```set vd:show to false.```
is issued, it only will apply to the second VectorRenderer, not the first one.
The first one is entirely orphaned, as far as kOS script is concerned.  The
reason it stays on the screen is becasue while it's orphaned from all kOSscript
references, it's not orphaned as far as C# is concerned because the UpdateHandler
still has a reference to it in its update list.

Alleviating this problem was the drive behind all of the following files having
small changes in them:
UpdateHandler.cs
Execution/KOSScopeObserver.cs
Execution/CPU.cs
Execution/Variable.cs

The changes I did to those files were for these reasons:
1) Changed the update queue in UpdateHandler to Dictionary instead of a List,
in order to trap any attempts to insert the same object into the update queue
more than once (so that UpdateHandler won't call the object's Update() multiple
times as would have happened with the previous List design in that case).)

2) Made a new interface, KOSScopeObserver, which is for any object that
might be put inside a kOS Variable which would like to be notified when
all its kOS variable references go away. This can be thought of as a type
of "soft orphaning".  It's orphaned from kOSscript but not necessarily from C#.
VectorRenderer is such an object.  (The only one so far).

3) Made the getter/setter for Variable.Value keep the link count updated
for any KOSScopeObserver object that is being attached to a kOS Variable name,
and when the count goes down to zero, it informs the KOSScopeObserver that it
has been "soft orphaned".

4) Made VectorRenderer respond to being "soft orphaned" by making its drawing
onscreen invisible and removing itself from UpdateHander, which should also orphan
it from C# as well making it reapable by the garbage collector.
resolves #91
Fix exception when trying to type a multiline instruction in the interpreter
Merge branch 'develop' of https://github.com/KSP-KOS/KOS into develop
Fix 87: Runtime errors inside a trigger now remove the trigger
Fix #88: Triggers declared in the interpreter now work as expected
Changed the POSITION suffix to correct for the difference between XYZ origin and ship position.
Also added POSITION to the vessel object.
Adds the ability to query or set whether the game is in Map View, using BindingsUniverse.

Rationale: Though not necessary, it's analogous to allowing the script
to set the WARP mode.

Syntax:
  // Querying:
  if MAPVIEW { print "I am on map view". } else { print "I am in flight view". }.

  // Setting:
  set MAPVIEW to true.
  print "Now looking at the map".
  wait 5.
  set MAPVIEW to false.
  print "Now looking at flight view".
Fix #100: FOR loop causing a kOS stack overflow
Resolves #86 using PRESERVE keyword instead of AGAIN.
disabling remotetech by default until i have more confidence in it
added srfprograde to shortcuts
simplified orbit constructor
bodies now have obt and parts have a vessel suffix
BREAKING WIP DockingPort:ORIENTATION is changed to facing #105
PARTs have a SHIP, not a VESSEL
you can now work with your target if it is a docking port
Merge branch 'trigger-preserve' into develop