sql: implement new API for node transformation

[erizocosmico]

Close #772

Instead of having TransformUp and TransformExpressionsUp in each
node, which was really error prone, now we have a different API.

Each node will have a WithChildren method that will receive
the children from which a new node of the same type will be created.
These nodes must come in the same number and order as the ones
returned by the Children method.

Expressioner nodes will also have WithExpressions method, which is
the same, except it will create a new node with its expressions
changed, instead of the children nodes.

The plan package will expose 3 new helpers:

• TransformUp: which transforms a node from the bottom-up.
• TransformExpressionsUp: which transforms expressions of a node from
  the bottom up.
• TransformExpressions: which transforms the expressions of just the
  given node.

Just like with nodes, expressions will also have a new WithChildren
method that does the exact same thing as it does in the nodes.

The expression package will expose a new helper:

• TransformUp: which transforms an expression from the bottom up.

The sql package now has one interface more: OpaqueNode. An opaque node is a node that acts as a black box and their children will not be transformed using the aforementioned helpers. SubqueryAlias node, for example, requires being opaque.

Caveats and limitations:

One thing that may seem odd is the limitation that WithChildren and
WithExpressions must receive the children in the exact same order and
number as they were returned from Expressions or Children.

This is because without this limitation there is no way to build
certain nodes. If we force this limitation on one, it would feel odd
not to have it elsewhere.

For example, take Case expression into account. It may or may not have
Expr, it has a list of branches (each having 2 expressions) and it
may or may not have an Else expression. If WithChildren receives N
children, how do we know where to put all these expressions?
This limitation allows us to build the node beacause we know the shape
of children must match the current shape.

[juanjux]

I solemnly declare here that I read everything.

[kuba--]

For me personally all transformations are very fragile (if sth. mysterious happens, it's most likely in some transformation).
This PR is huge, but for the first insight, it reduces a little bit number of possible mistakes (even shadowed nodes).

[ajnavarro]

@erizocosmico could you rebase please?

[erizocosmico]

Done

[erizocosmico]

Updated so that resolve_having can take advantage of the new WithChildren API