Support non-trivial register sizes

[mstechly]

Input register sizes must define new input parameters. This means it is fine to define an input register as having size $N$, but it is not fine to try and define the input size as $2N$, or any other function $f(N)$ (where $N$ is some other param, supplied either as an input param, or as an input size param for another input register).

However, one can imagine many cases where one may want to assert that the input register size is some arbitrary function of another input parameter, such as requiring that one input register is twice the size of another. Currently, this cannot be supported. This is because doing so would introduce a number of non-trivial problems. A loose overview of these are as follows:

1. If input register sizes can be arbitrary functions (a.k.a are non-trivial), then they effectively represent outputs of the associated function.
2. Then, if an output port is connected to a non-trivial input, then there is no clear way to interpret how to propagate the associated parameters through the function network.
3. In simple cases, such as an input register size of $2N$ connected to an output port with register size $f(a, b)$, it's clear that this fixes $N=f(a,b)/2$, and hence uses of $N$ can be correctly substituted the other expressions of the function.
4. In more complicated cases, such as an output port is $f(a, b)$ and is connected to an input port with non-trivial size $g(c,d)$. This would hence require that $f(a,b)=g(c,d)$. In this case it's clear that there is no simple, general way to propagate the constraints of the output register size further into the function network.
5. Such cases would therefore create a set of additional "constraints", which exist alongside the final compiled function. It is not clear to me how one would systematically resolve such constrains automatically, nor whether sympy support such advanced analytic solving features.
6. If constraints can't be automatically resolved, this would naturally lead to a proliferation of parameters in the function, making the resultant expressions hard to interpret (without manually resolving the constraints first).

These are the issues that come to mind initially, however, I am sure there are others one might need to consider also. This issue is to highlight this as a known issue in the current implementation, and to provide a space for us to discuss whether this is a feature we need to support in the long-term.

This might be easier to solve if we move to graph based compilation (https://github.com/PsiQ/bartiq/issues/9).

[mstechly]

Since one can have non-trivial input register sizes in Qualtran, this is an issue for Qualtran -> QREF conversion.

Here's a branch with a precompilation step which handles simple cases by introducing a new local_variable. However, compilation works only if a given symbol is not used in resources, cause otherwise we run into the issues mentioned above. https://github.com/PsiQ/bartiq/tree/10-non-trivial-ports-workaround