Change UFL input to static single assignment (SSA) form

[gmarkall]

Things are going to go wrong if a variable is re-used: Since we store things in a dict with the key being the name of the target of an assignment, some objects will get lost. We need to transform the source into single-assignment form first (then modify the form backend so it doesn't rely on counting things).

[gmarkall]

We discussed in a meeting the issue of control flow occurring, and the fact that we need to somehow implement the phi node in the Python AST if we convert it to SSA form, because the pipeline goes:

Input parser -> String processor -> AST Transformations (convert to SSA) -> Execute AST -> ...

However, since we're not aiming for getting it into SSA form for the usual reasons, but merely need it to be "sufficiently SSA" that we don't end up overwriting objects with the same name in our internal data structures, maybe we can re-use identifiers between branches.

An illustrative example: typically, a piece of code like:

if condition:
    a = 1
else:
    a = 2

will become in SSA form:

if condition:
    a_1 = 1
else:
    a_2 = 2
a_3 = phi(a_1, a_2)

However, this is more than we need. Since we are initially aiming at implementing branches on options in the FLML, our pre-processing step can just re-use the identifier:

if condition:
    a_1 = 1
else:
    a_1 = 2

This way we don't need to worry about implementing phi nodes, but since only the if or the else branch is taken, we won't ever end up re-assigning the same name.

Just to be explicit, the case where we still need to re-name things is when they get re-assigned in the same branch (or not in any branch), e.g.:

if condition:
    a = 1
    <use of a>
    a = 2
    <another use of a
else:
    a = 3

Will need to become:

if condition:
    a_1 = 1
    <use of a_1>
    a_2 = 2
    <use of a_2>
else:
    a_2 = 3

This also highlights the fact that if we are going to use the same identifier in two different branches, the last name in each branch needs to be the same.

[gmarkall]

This is going to become an irrelevant thing to do when we move to runtime code generation.