KSPFields - not done yet but checking it to switch branches.
commit in preparation for pulling erendrake's new suffix system
commit in prep for pulling from erendrake
Merge branch 'develop' of https://github.com/KSP-KOS/KOS into KSPField-using-new-suffixes

Conflicts:
	src/kOS.Safe/Encapsulation/Structure.cs
	src/kOS/Suffixed/Part/PartValue.cs
Probably still needs a lot of work.  Checking in for erendrake to be able to pull and try
Added tree-walk suffixes to PartValue.

With these new suffixes you can walk the parts of a vessel with
tree thinking:

New suffixes:

VesselTarget :ROOTPART
PartValue :PARENT
PartValue :CHILDREN
Remove redundant extra "MODULES" suffix.

I didn't see that there was already a MODULES suffix on PartValue
when I added my own MODULES suffix.  The previous MODULES suffix
wasn't usable anyway because it returned a ListValue of non-kOS types
the user can't use, so I just got rid of it.
Removed underscores from PartModuleFields terms.

These terms are no longer used as direct suffix identifiers and therefore no longer need to have the spaces protected.
Minor compile error (why didn't the build complain?)
Uses method and property syntax interchangably.

Before this change, the way it worked was this:

Calling someobject:somesuffix_A. Somesuffix_A is NOT meant to use
parentheses (it was made with 'new Suffix..' rather than 'new NoArgsSuffix..')
creates this:

  push $someobject
  push somesuffix_a
  getmember     // leaves result of GetSuffix() on the stack, which is
                // an object atop the stack that the kos script can use.

Calling someobject:somesuffix_B(). Somesuffix_B IS meant to use
parentheses (it was made with 'new NoArgsSuffix..' rather than 'new Suffix..')
creates this:

  push $someobject
  push somesuffix_b
  getmember     // leaves result of GetSuffix() on the stack, which is
                // an object of type Delegate that hasn't been invoked yet.
  push $<argstart>  // Marker for the bottom of the args on the stack
  call <indirect> // Consumes the (lack of) arguments on the stack, and the
                  // $<argstart> marker, then Invokes the Delegate, leaving
		  // its return val on the stack.

The change is two-way:

1: For allowing thing:suffix() when it's supposed to be thing:suffix :

Thing:suffix() will build code looking like the "somesuffix_b" example
above, even though the value that getMember put on the stack isn't
really a delegate, so it fails when it tries to call that "delegate".
The fix is to have OpcodeCall notice when it's being used on an indirect
call despite the fact that said object isn't a delegate.  In that case it
should just consume the stack down until that non-delegate object is on top,
and just quit.  The non-delegate that GetMember left on the stack IS the
return value of the expression.

2: For allowing thing:suffix when it's supposed to be thing:suffix() :

Thing:suffix will build code looking like the "somesuffix_a" example
above, even though the value that getMember put on the stack is
really a Delegate that hasn't been invoked yet, and the value that
is passed back to the kos script on the stack is meant to be the result
of that invocation that hasn't occured.  To fix this, OpcodeGetMember needs
to divert the execution path over into OpcodeCall and get OpcodeCall to
invoke the delegate as if it had been built using the "somesuffix_b"
pattern seen above.  But it has to know *when* to do this, which is the
messy part.  Because as you can see the code for "somesuffix_a" and
for "somesuffix_b" look identical during the first 3 instructions.  Until
it peeks ahead at the next instructions, it doesn't know if it's being
called as part of a method invocation or not.  It should only divert
into OpcodeCall when it knows an OpcodeCall isn't about to come up next.
To make this work without peeking ahead in the program to see, I subclassed
OpcodeGetMethod with OpcodeGetMember - it does the exact same thing, except
that when the instrucion is an OpcodeGetMember, it knows that the compiler
built the upcoming OpcodeCall already, and when it's an OpcodeGetMember,
it knows the compiler didn't.  Only when it's an OpcodeGetMember should
it perform the logic to divert into OpcodeCall upon seeing a delegate.
If it's an OpcodeGetMethod, it knows such an OpcodeCall is on its way.
method call return null no longer gives bogus error.

Previously, if you had this:
    // FOO IS some sort of list.
    SET ITER TO FOO:ITER.

And did this:
    ITER:RESET.

Instead of this:
    ITER:RESET().

Then it *would* work, but after calling Enumerator.GetMethod("RESET")
it would incorrectly claim "RESET" is not a suffix of ITER.  This was
because Structure.GetMethod() uses null returns as its way of
communicating that a suffix doesn't exist.  It should have used an
exception, which is what it does now.
NUnit tests changed for new GetMember exceptions.

Some of the Nunit tests failed because they expected GetMember to
return null (like it used to) on missing suffixes instead of
throwing an exception on missing suffixes.
Add support for the CKAN.

Provided kOS is released through KerbalStuff, you'll never have to
change this file.

It *will* need to be changed if it's installed differently, or starts
to depend on other mods, of course.  :)
Merge pull request #285 from pjf/284_ckan_support

CKAN support
Merge remote-tracking branch 'Dunbaratu/KSPField-using-new-suffixes' into develop

Conflicts:
	src/kOS.Safe/Encapsulation/ListValue.cs
Merge branch 'develop' of github.com:KSP-KOS/KOS into develop
review changes
Merge remote-tracking branch 'Dunbaratu/partvalue-tree-sufixes' into develop

Conflicts:
	src/kOS/Suffixed/Part/PartValue.cs
review changes, added HASPARENT
revert class rename