Runtime ExpressionParser caching issues

[fkleuver]

@bigopon discovered a problem today where trying to parse an interpolation expression will actually return the cached value of a previously parsed non-interpolation expression.

I didn't think the caching through very well at the time I changed it, nor tested it very properly, so after looking at it a bit more closely I think this mechanism is due for a rework. I'm just putting my thoughts out here to give you a heads up on what I'll be working on soonish (I may or may not do some more templating tests first)

I'm considering tackling this together with improving the coverage on the renderer and making targeted instruction types numeric again (using an array as the backing store) so they can more easily be inserted (addressing #182), swapped, and have some cleverness with bitwise ops applied to them when appropriate*.

There would be 3 or so lookups in the expression parser, one for each set of parsing rules (interpolation, iterator statement and normal expressions)

The instruction types would be split up again per binding type / command, each having a unique number. The numbers of the instruction types can then, via bitwise operators, be translated to one out of these cache indices.

With all this in mind there are some const enums that need to be cleaned up. The BindingType and ExpressionKind enums have become an incoherent mess and I'd like to try to just get rid of them. Same goes for some of those direct prototype assignments on instruction classes and AST nodes.

Naturally this would also touch the AST and expression parser and probably break a few thousand tests, so those need to be tidied up as well. So that's a fairly big chunk of work upcoming, but I think things will be much cleaner and easier to understand when it's done.

[EisenbergEffect]

Sounds good.

[bigopon]

making targeted instruction types numeric again (using an array as the backing store) so they can more easily be inserted (addressing #182), swapped, and have some cleverness with bitwise ops applied to them when appropriate*.

Will this result in array with holes? Quite curious about the plan