Further integrating javacc and jjtree.

[Jonathan Revusky]

As I said before, my feeling about jjtree was always that it was
something grafted onto javacc as an afterthought, in a rather artificial
sort of way.

So my latest commits have basically been integrating the two things much
more. As I said before, in KawaDD, there is no javacc/jjtree dichotomy.
The tree-building code is in the templates, and depending on your
configuration options, those parts of the templates are turned on or not.

As of the latest commit, Token implements the Node interface and, by
default (though I might change the default) if tree building is enabled,
it includes the Token objects in the AST.

And there is a new configuration option:

TOKENS_ARE_NODES=true/false

which can be turned on or off (and I still haven't decided what the
factory setting default is going to be.)

Of course, this only gives you the ability to add your Tokens to your
AST on an all or nothing basis. There is surely the need now to add some
syntax so that you can have fine-tuned control in your grammars to
specify which types of tokens get put into the AST.

Anyway, another aspect of where this is heading is that the ASTXXXX
objects and the Token object all implement the Node interface, so the
preferred way of accessing all of these objects would be through that
base Node API -- well, obviously assuming that you can get away with it.
(Similarly, it's best for flexibility to access either ArrayList or
LinkedList just using the java.util.List base interface, except for the
cases where you just can't because it doesn't work... ;-))

So, the preferred way of reading the beginLine/beginColumn from a Token,
say, would be via the Node.getBeginLine()/getEndLine() API's rather than
directly accessing those fields, which is the traditional approach. This
would tend to nudge people towards programming practices that are
considered better practice -- oh, and that reminds me, I made
TokenMgrError a subclass of RuntimeException rather than Error, which
was really a very bizarre thing. How is a TokenMgrError a peer of things
like OutOfMemoryError and StackOverFlowError and so on? XXXError is for
real system-level problems. (Of course, TokenMgrError should be
TokenMgrException now, but I'll leave it with the same name for now
because I want people's existing JavaCC code to compile (or mostly
compile, more realistically) when they try KawaDD...

JR