Smarter solving

[croyzor]

In our journey to close #28 and #29, there are places where we could be doing better. For example, we fail on the following example:

mapVec(X :: *, Y :: *, { X -> Y }, n :: #, Vec(X, n)) -> Vec(Y, n)
mapVec(_, _, _, _, []) = []
mapVec(_, _, f, _, x ,- xs) = f(x) ,- mapVec(!, !, f, !, xs)

because we can't solve the number argument to the recursive call to mapVec. If we help the typechecker by matching on the number as succ(_) then we can work it out, but this shouldn't be necessary! We know that mapVec preserves vector size, so we should be able to work out from the use of cons that the argument needs to be n - 1

[croyzor]

Another good application of this would be with the fanout/fanin operators. They are checkable currently so the places they can be used is limited, but we could guess at the expected size using this framework, they'd be much more useful!
e.g.

f(Vec(Qubit, 2)) -o Bit
f = ...

g(Qubit, Qubit) -o Bit
g = [\/]; f

h(Qubit, Qubit) -o Bit
h = [\/]; ..; f

g succeeds but h fails. I think we could do better!