Parser changes needed to support eventual Suffix function call syntax.

This does not actually implement the suffix function calls yet, but it
modifies the parser as needed to make the following into a valid
syntax:
   VARIABLE:FIRSTSUFFIX:SECONDSUFFIX(arg,arg,arg).

(Right now if you actually try doing this, it will give runtime exceptions
because the virtual machine doesn't implement the delegate method calls
in the kRISC opcodes yet).

In fixing this, I **think** I may finally have slain the beast of messy
syntax that was also making some mixtures of suffixes, indeces, and
function calls not be mixable.  (I *think*).  The same change may also
now start allowing complex things like this:

   SET VARIABLE[10]:SUFFIX(arg):MORESUFFIX  to 10.

TO be parsed correctly.  The compiler won't actually build the right code
to execute it properly yet, but that's now potentially possible because at
least the parser isn't blocking the way like it had been.

I finally found the place where the parse rules were causing the LL(1)
parser to hit ambiguity, and it was in the attempt to support more complex
expressions using the deprecated "#" syntax for loop indeces.  There's a
*reason* languages use an open/close syntax like [..] or (..) for array
indeces.  Parsing multidimensional array indeces without that rigid help
makes simple parsers barf.  When I reduced the "#" usage to only allowing
raw numbers or raw variable names again, the ambiguity went away and I could
fix the parse tree.  This may *slightly* break backward compatibility, if
anyone was trying to use the old syntax to do very complex things, but I
consider that acceptable, as that syntax is holding us back from fixing
bigger problems.