Parser changes needed to support eventual Suffix function call syntax.

### ~~DO NOT PULL THIS YET~~
### Okay go ahead and pull it now.

~~*I've discovered some edge cases the new parser changes don't deal with correctly yet - things that broke unexpectedly - I'm still working through them.*~~ - I worked through them.


~~This does not actually implement the suffix function calls yet~~ *(actually, yes it does now)*, 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).~~ *(now implemented)*

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.