Restructure Expression objects

[kitchoi]

This issue proposes restructuring the internal data structures supporting Expression introduced in #1067. As it stands, this should not have any impact on the user-facing API.

An initial attempt has been made in this commit: 5657dd4
For future proofing (as I don't trust GH not to garbage collect this), here is the patch created from this commit:
0001-Restructuring-Expression-not-yet-tested-with-recursi.patch.txt

While this new structure seems to work now, it has not been tested for future proofing with recursion support. Recursion is one that has profound impact on the data structure, and therefore it would be worth testing the proposed structure with recursion, unless it is decided that recursion will never be supported.

For reference, on_trait_change supports "*" for recursion support, namely "root.node*.value" will match root.node.value, root.node.node.value, and so on. It was decided that as a first cut implementation, observe will not support this feature.

[mdickinson]

I don't think recursion is relevant here: the expression itself is not recursive, even when the data structure it describes is. An example like root.node*.value might look something like NameExpression("root").then(OneOrMore(NameExpression("node")).then(NameExpression("value")) in the expression language. It's unusual for the data structure representing an expression to be anything other than a tree.

[kitchoi]

I might not have used the right words to describe the challenge I faced when I last tackled recursion support here. I just wanted to mention that the feature has been proposed and deferred, and therefore it is worth making sure that the refactoring we attempt is still going to support this when it is needed.

[mdickinson]

I think we shouldn't be worrying about future recursion support. If we keep the design clean, we'll be able to adapt it to add that support if and when it's needed.

[kitchoi]

I am sure it will work, but I'd still like to check if that's okay.