Gr/parsing overhaul

[GeorgeR227]

This pull request is meant to improve the parsing and creation of Decapodes.

[lukem12345]

Commit f4c5a1e fixes a hitherto unknown bug with a composed vector of functions applied to two variables, i.e. a chain of Op2s. The computational meaning of a chain of operators such as C == \circ(f,g)(A,B) is not yet decided. This could mean that the function g is an Op2 as we typically understand it, and f is an Op1, or it could mean that g is an Op2 as we typically understand it, and f is an Op2 that takes a copy of g(A,B) as its two arguments.

No Decapode use cases have run into this scenario before, so how to compile this is still unknown. The compile function should be amended to check if an :op2 is a vector, and raise a legible error if so.

[lukem12345]

Currently, the following Decapode does not parse:

G = SummationDecapode(parse_decapode(quote
	(A,B,C,D,E)::infer{X}
	B == \circ(g)(f(A))
	E == \circ(i)(h(C,D))
end))

Interestingly, we note that the following does parse:

G = SummationDecapode(parse_decapode(quote
	(A,B,C,D,E)::infer{X}
	B == g(\circ(f)(A))
	E == i(\circ(h)(C,D))
end))

Both of these cases should be supported.

[GeorgeR227]

I believe that issue should be solved by commit a3b1d7f.

[lukem12345]

New features that this branch allows are:

• No need to parameterize forms over space (i.e. {X})
• Support Parsing Literals #94 Literals
• Multiplication without parentheses
• Variables do not need to be declared before being used
• Fix Issues with TVars parsing #84 Tvar parsing
• Check that the type of a declared Var is in some allowed subset