Multiple file is now supported

Basically tested the new written preprocessor.

In earlier time, I said that cscript should support and compatible with
`cpp`(a c preprocessor program) completely, and with internal macros.

Today I have done the latter one, with written this part and tested the
first demonstration.

It does now support importing another program in one. `import` is a new
designated macro, which forms like `include` in C, for example:
  #import "file.csc"            /* import from local directory */
  #  import  "another_file.csc" /* spaces doesn't matter */
  #import <system.csc>          /* import from system path (not yet
                                   finished) */
And this macro hehaves like `include` in C completely.

I will soon introduce the further features, such as `global` keyword,
which does declare a variable's life-scope to global and make it commonly
visible in mulitple files (for variable sharing).

And the external `cpp` will soon come, too. This feature can provid
a real preprocess before the program is first lexical scanned by the
scanner. That would be quite wonderful as it could provide much further
useful functions such as conditional macros.

* TESTED
    - `import` macro for internal importing
* FINISHED BUT NOT TESTED
    - line number resetting macros
* NOT FINISHED
    - `import` with system path(this needs array or environmental
                                variables support)

And this commitment includes other not interfering subtle changes.
`global` keyword addition and other changes

First, most important, the keyword `global` is now added to this
programming language. Which does promote(later I'll explain the word's
exactly meaning) or declare variables to/in global scope.

I need to re-elaborate the scope's concept in cscript.

As you know, variables name will be found along the ancestors chain of
name stacks, which means stacks that store names(a.k.a. symbol_table),
such as RunStack or Runtime.

RunStack is a general name scope, provides a place for storing local
variables. Once a statment, except of expression statement, is executed,
it will create a sub runstack under the current one, that means,
operations inside this statement can be able to access the variables of
parent runstack or even change them, after this statement is executed
finished, all local variables, just in this new-sub-runstack, will be
cleared.

However, some operations, such as function calling, won't share the
scope with current one. For example:

  def foo()
     a = 1;  /* A new local variable, won't influence the outter one */
  end
  a = 2;
  foo();
  EMIT a;    /* emits 2, it won't be changed */

A function call doesn't create a sub-runstack but a call-stack. The most
enormous difference between the former one is that it create a
completely new runstack which is isolated from the one where the call is.

A call stack doesn't store variables, as once a call operation
happens, the call stack will create a run stack inside, however, just
like above says, the run stack has no parent.

To separate the call stack and the run stack is necessary, which
provides many conveniences, for example, you can now easily trace a
call-chain.

Now the problem is how to share variables globally between calls. This
is why **global** keyword is needed.

Like above code, you can change it as:

  def foo()
     a = 1;     /* actually changed the variables defined below, as
                   it is globally shown now */
  end
  global a = 2; /* add a `global` keyword to instruct the variable will
                   be defined in global scope */
  foo();
  EMIT a;    /* emits 1 */

Global scope is a special scope in a program, as it is commonly shown in
the whole program whereever. Technically, it is implemented as a
symbol_table also but under the Runtime. Because of one program has only
one shared runtime, the variables inside will be shared, too.

Actually, also technically, function's definitions is default in the
global scope too, that is why you can call a function inside a function
call. (You can say it might cause the pollution between files. Yes, I
used to think about this, the solution can be another keyword -
`static`, which delimit the scope in current file only. I'll implement
this in the next step.)

What's the form of `global` keyword?

Basically, it accept a variable's name, like:

  global foo;

which define a global variable `foo` with initial value `null`.

And you might designate an initial assignment:

  global foo = 'hello';

Or gather them up:

  global foo, bar = 1, baz = 'hello';

Notably, the priority between the declarations/definitions is
one-by-one left-to-right, which means, you can even use the value of
just defined variables, like:

  global foo = 1, bar = foo + 1;

And even you can promote an existing local variable into global scope:

  foo = 1;
  global foo;  /* `foo`'s value is still 1 but now global */

Or assign a new value while promoting:

  foo = 1;
  global foo = foo + 1;

All above forms accept gathering up.

Changes:
    * `#import` macro now could be recognized even there's spaces
       between `#` and `import`. And the spaces between `import` and the
       filename is now nor limited.
    * `global` keyword
    * new `Mark` nodetype in parser. It is used to indicate an
      unexecutable node with fixed pattern, it just derives from Control
    * `very_simple_test` is now renamed as `more_simple_test` in the
      test module. And which now do print synatx tree in JSON form
      instead of the raw ruby-hash when argument `synatx` is designated.
    * new `undef` and `undef_local` methods in SymbolTable, which
      unset defined variables. (public callable)
    * new `#file "filename"` preprocessing instruction. It could special
      current file dynamically in program, especially useful in string
      execution.
    * specially `#file auto` could auto detect current file as the
      program file. (is just $0)

Bug Fixes:
    * `@root_stack` in Runtime class is now unavalible. As all file has
      its own run stack without pollution. The `@current_stack` points
      to the run stack of current executing file. This change is purpose
      to preventing top scope pollution between files imported.

Known Bugs:
    * Preprocessor instructions will still be executed even inside
      comments. For example:

        /* The following line still works
        #file auto
        And the comments are ignored normally */

      A temporary solution is:

        /* Comment it as line comment
        # #file auto
         */

To write the commit log spends me two hours. It's the time to go to bed!
Have a nice dream.

Shou Ya