Resolves #822 globalvar variable access in scripts

Instead of reopening #824, I wanted to open another pull request offering a different strategy for handling the issue defined by #822.  These changes will make it so that variables within scripts will be put on hold (considered ambiguous at the time) until all script/object parsing is done.  Once all globalvar declarations have been evaluated, each variable* that was not explicitly declared will be disambiguated and stored either as local variables to calling objects or left as globals.  Keep in mind that this method introduces a new syntax symbol 'a' for the fake keyword 'amb'.  This is to prevent scripts and with statements from putting in self.varname, forcing the parser to figure out the easily fooled task of determining whether self.varname was entered by the coder or by the compiler.  I also need to mention that this method also matches <b>GM7 behavior</b>, which means that a variable defined as globalvar will have priority over non-dot-accessed local vars, but not scoped vars.
*Technically speaking, there is no need to consider all non-dot-accessed variables as ambiguous.  It really only affects scripts/timelines and with statements.  This is because object code does not require varaccess calls to globalvars and regular vars, so it is acceptable to be left in an ambiguous state.  I can optimize this out, if necessary (ambiguous linking should be a very fast process regardless.)

This commit also includes a couple of other changes.  Calling something like <code>type varname = func(a,b,c)</code> from within a script or with statement should properly handle changing a, b, and c to self.a, self.b, and self.c (only 'a' was affected previously.)  The other change is that <code>globalvar varname;</code> and <code>global.varname;</code> now refer to the same variable.  This matches the behavior of GM7.