Some work to rework/optimize how variable lookup works.
It seems to give about 30% spedup on richmoore's cordic benchmark, 20% on his md5 bench, and 10% on IB (though normal web will likely benefit far less);
but it is also incomplete --- has known bugs, and is not well-tested at all, so surely has unknown ones as well, but the core design is there.
Oh, and the naming of stuff kinda sucks.

More specifically, this does the following:

1. Split up the resolution and operation code in the *ResolveNode clases into the resolver template and the operation handler code.
The former handles the read, and if needed, write, while the latter just does the operation. This permits to have multiple lookup strategies --
DynamicResolver, StaticResolver, and NonLocalResolver..

2. Make VarDecl handling inside a function execution context construct a symbol table inside the body node, assigning locals numeric IDs. Do this the first time the function is called, also for formal parameters..

3. Change ActivationImp to have an array for locals, and to use the body's symbol table as a fallback for named access; provide StaticResolver which indexes directly into the array w/o any symbolic lookup; make parameter passing code write in directly to the locals array.

4. Provide a simple splice/replace node visitor infrastructure.
Needs a lot of work on list handling, though.

5. Use the above to replace DynamicResolver useage with StaticResolver or NonLocalResolver when appropriate (eval safety not handled yet, but I know how to do it)