Clean up normalized AST type

[jgrosso]

Currently, it's difficult to work with as well as too restrictive in some places but too lax in others. A big part of the issues revolves around how many syntax issues we want to push fully onto Haskell and how much we want to catch in the Axel normalization phase. Now that errors are sourcemapped pretty well, maybe we can get away with pushing as much as possible onto Haskell.

These issues become even more important if we decide to encourage end-users to use Axel.Normalize in macros.

Example problems:

1. Is there a way to more concisely write (or specify the behavior of, maybe with a DSL) Axel.Normalize.normalizeStatement and Axel.Normalize.normalizeExpression? Their current implementations are difficult to modify.

2. Too restrictive/lax: For example, constructors in data declarations used to be "function applications" only, but that meant that even constructors with no fields would need to be wrapped with parentheses (e.g. (data Foo (Bar)) was required instead of (data Foo Bar)). To fix this, Axel.AST.DataDeclaration was expanded to allow AST.Expressions as constructors in data declarations, but that means that e.g. string literals would be valid constructors (even though this is invalid Haskell). This is an example of the Haskell <=> Axel tradeoff in terms of where we handle errors.

3. Axel.AST.RestrictedImport should be renamed to Axel.AST.UnqualifiedImport, now that Axel.AST.UnqualifiedImport has been subsumed into RestrictedImport's functionality.

4. AST.Identifier is just an alias for Text, which makes it reasonably unsafe to work with. Should it instead become a newtype which wraps Text?

Some of these issues could be solved by using lists to represent AST elements where there are a variable number of elements (e.g. constraint lists), since then we don't have to manually convert Expressions into lists of Expressions (by pattern matching on EEmptySExpression and EFunctionApplication).

Another potential improvement would be to use open unions (e.g. http://hackage.haskell.org/package/world-peace-1.0.1.0/docs/Data-WorldPeace.html) instead of e.g. requiring special Statement and Expression types. However, this is most likely only useful if we decide to stay with the "restrict as much as possible" route. Also, would using an uncommon technique like open unions make it more difficult for end-users to use the Axel.Normalize API?