A large part of the way toward #258

Good news and bad.

Good news, a LOT of the functionality is fixed and working.

In fact it's faster to describe what does NOT work.

Bad news: this is what does NOT work:

Auto-extensions:
   Auto-extensions on the LOCAL volume do not work like they do
   on the Archive, because the logic of auto-extensions looks
   like it was only implemented in the methods of Archive, and
   not the base class's methods in Volume.

   (What I mean by auto-extensions is: You try to write a file
   called "foo", and actually get a file called "foo.ks".)

   This is probably fixable by mimicking what was done for Archive.cs
   in Volume.cs, but I didn't want to touch that as I suspect
   @erendrake will know better if that logic exists somewhere already
   in what he wrote but reverted.

Run command:
   The run command only works at one depth from the interactive
   shell, and not in programs that call programs.  In other words,
   the interpreter can invoke prog1, but prog1 can't invoke prog2.
   I know exactly why this doesn't work, but fixing it does not look
   simple as it probably means moving some compile-time logic into
   run-time logic.

   To see what I mean, look for the places in the code where I
   added the annotation "!!OH CRUD" in a comment.  Those are the
   comments highlighting the problem - the compiler assumes it
   already knows the name of the filename you are using in the RUN
   command, and it won't let you leave it as a decision for later
   at runtime.  The move to using any arbitrary expression *mandates*
   that the filename be *calculated* at runtime, rather than fixed
   at compile time so we have to find a way to move that logic from the
   compiler to the runtime opcodes.

What does work now, and how it works:
--------------------------------------

This is the basic design of how I did it:

- In the TinyPG file, All places expecting a filename now accept any
expression instead.

- In the Compiler.cs file, there were many places where a file command
just tried reading the identifier text directly without sending it through
the rest of the levels of parse tree.  These have been replaced with
a call to VisitNode so that the entire expression may be evaluated and
pushed on the stack there.

- If that expression happens to be a single identifier, and the identifier
refers to a variable that doesn't exist, the problem is deferred until
later.  (Normally the error "Undefined variable" is not caught by the
compiler.  It's not detected until runtime, which suits me just fine here.
At compile time all it does is insert an Opcode to try retrieving the
variable.  That's it.  At runtime it will notice that the variable can't
be found.).

- Added a flag to popping values off the stack that says "in this
context it's acceptable to have the value be not-found.  If it's a
variable that's not found, then just return it's name as if it was
the value."  This flag is optional and defaulted to false so it has
no effect on most of the places that code calls CPU.PopValue().  But
the few places we want this behavior (when executing the file
manipulating functions) we turn it on.

    Thus when getting a value like "$myvar" when myvar doesn't exist,
    will just return the string "myvar" in these special cases, but
    not in the normal case.

- Added the logic to coerce a filename with no extension into a
filename with a .ks extension if wanted.

So the thinking that happens when you try to do something like this:

  LOG "hello" to FOO.

Is this in the logfile() function execution:

  "Okay, pop the string to print from the stack, and then
  pop the filename to print to... with the 'barewordOkay' flag to true."

Then the CPU.PopStack(true) call does this:

  "Okay, let's see, the thing atop the stack is $FOO, that's a variable,
  go look it up.  Darn there is no $FOO.  Oh, but in this case I was told
  that barewords were okay, so instead of bombing out I'll return 'FOO'."

Then the LOG execution goes on as normal, just as if the script had
said this instead:

  LOG "hello" to "FOO".

This logic covered all the cases... and the following example works as
expected:

LOG "hello 1" TO somefile.
LOG "hello 2" TO "somefile".
LOG "hello 3" TO "some" + "file".
SET myFileName to "some" + "file".
LOG "hello 4" TO myFileName.
LOG "hello 5" TO "somefile.txt".

This results in two files:
somefile.ks :
hello 1
hello 2
hello 3
hello 4

somefile.txt :
hello 5
Added fix to the "run" problem.

The fix is that the "run" command, unlike all the others,
requires a fixed known name at runtime.

So you can do this:
   run ascend.ks(arg1,arg2,arg3).
and this:
   run ascend.ksm(arg1,arg2,arg3).
and this:
   run ascend(arg1,arg2,arg3). // defaults to .ksm, then tries .ks.

But you can't do this:
   run "ascend"(arg1,arg2,arg3).
or do this:
   set var to "ascend".
   run var(arg1,arg2,arg3).

As part of this, I made it allow filenames as bare words with extensions,
like so:

   copy file1.ks to file1.txt.

You can put a dot in a bareword filename provided it has at least one
character after the dot. what you can't do is work with a file called
"file." .  That's because when you say "edit file1." it has to take
the dot as an end-of-statement marker, not part of the filename.
Reinstanted "TO file" being optional on COMPILE.
Resolves #379.

The actual problem, after looking at it, only happened
on the error where you forgot the closing dot of a command,
like you did this:

    print "hello"

instead of this

    print "hello.

It didn't happen on other syntax errors, and it only happened
in the live interpreter.

The cause was the fact that the interpreter appends an
OpcodeEOF to the end of the program context in a way that
is outside the normal compile process, and in so doing
it's missing the debug data, like so:

  Code Fragment
  File                 Line:Col IP   opcode operand
  ----                 ----:--- ---- ---------------------
			  0:0   0000 jump 1
  interpreter history     2:1   0001 push $sfasdfsd
  interpreter history     2:1   0002 pop
  interpreter history     4:7   0003 push hello
  interpreter history     4:7   0004 call print()
  interpreter history     5:7   0005 push $asdf
  interpreter history     5:7   0006 call print()
                          0:0   0007 EOF  <<--INSTRUCTION POINTER

So when the syntax error happens at the EOF, it doesn't
know during the stack trace that it came from user typing.
The lack of a program name or "interpreter history" makes it
believe it came from an internal problem.

The solution I implemented was to perform a special case in KSPLogger
when the opcode is OpcodeEOF and bypass the normal attempts
to pull it out of the source line - there is no source line,
its after the end of the source code that the error happened.
Recoreded the changelog issues to markdown
Merge remote-tracking branch 'Dunbaratu/changelog-0.15' into develop
Merge branch 'develop' of github.com:KSP-KOS/KOS into develop