Updated controlled ApproximatelyMultiplexZ, added test

[DmitryVasilevsky]

This PR implements the old suggestion by @msoeken and resolves the last remaining item in the issue #1104.

The suggestion was "Instead of performing Controlled X apply an AND chain. I think you added such an operation for the PhaseUp..."

Also introduces a test for controlled version of preparation.

Closes #1104

[github-actions]

Change in memory usage detected by benchmark.

Memory Report for eed7a1f

Test	This Branch	On Main	Difference
compile core + standard lib	24735222 bytes	24729454 bytes	5768 bytes

[swernli]

What impact does this have on the resource counts? The two approaches look almost the same in terms of how they apply AND under the covers, just one recursively while the other is iterative, so I'm not sure why one would be preferred over the other.

[msoeken]

One can still save a factor of 2x by only doing the forward direction of the multi-controlled X gate (chain of computing ANDs) and then the backward direction (chain of uncomputing ANDs) afterwards. However, this will require to allocate the helper qubits in this operation.

For a 3-qubit controlRegister the trace would be as follows:

use helper = Qubit[1];

And(controlRegister[0], controlRegister[1], helper[0]);
And(controlRegister[1], helper[0], target);

ApproximatelyMultiplexZ(tolerance, coefficients1, control, target);

Adjoint And(controlRegister[1], helper[0], target);
Adjoint And(controlRegister[0], controlRegister[1], helper[0]);

[msoeken]

What impact does this have on the resource counts? The two approaches look almost the same in terms of how they apply AND under the covers, just one recursively while the other is iterative, so I'm not sure why one would be preferred over the other.

Maybe it's worth to add tests for logical counts to the test suite for some operations like these ones. We can use the LogicalCounst backend in Rust or the logical_counts function in Python, depending on where the tests live.