Refactor quimb backend

[alecandido]

Adopt Qibo QASM parser, i.e. construct the Quimb Circuit object directly from Qibo Circuit.

The code inside qibotn is not any longer tailored for QFT. So, feel free to try with any other Qibo circuit, and report in case something is broken.

(a known limitation is that Qibo gates have both .qubits attribute and `.target_qubits', but the latter is not used at present time; then, if qubits are renamed afterwards, w.r.t. the canonical naming, this is not propagated to Quimb - but I expect to be non-trivial to hit this corner case)

QASM

Notice that the function still reads QASM, so in the tests a QASM string is still generated and passed to the function. But instead of writing a dedicated parser, the Qibo parser is used, and it generates a temporary Qibo circuit inside the quimb backend.
So, at the moment there are two circuits: one in the tests, generating the QFT, that than is dump to QASM (still in tests), and the other inside the backend, loaded from the QASM.

If at some point we don't care any longer about accepting QASM input, we can always replace the input of eval() function (still lacking a better, but simple, name, given that I'm shadowing a built-in) directly with a Qibo circuit, and delegate the QASM parsing (i.e. the call to qibo.models.Circuit.from_qasm()) to the user.

Swaps

Before there was a dedicated handling for swaps. Given that Qibo is treating them as any other gate, at the moment I suppressed them everywhere, but in the qibo.models.QFT circuit generation.
If you are aware of any explicit reason to treat them separately from the rest, please explain me and I will try to fix it accordingly.

[alecandido]

@scarrazza workflows are not running because we exceed our quota.

[alecandido]

However, locally on my Linux machine tests are now passing, and they are the exact same of #8

[nitinshivaraman]

Looks good!

[alecandido]

Looks good!

Thanks, I'll wait for another review and then we can merge :)

[liweintu]

Looks good, thanks.

[liweintu]

After merging, pytest hit an error below. Seems the cause is that quimb_time is too small when , failing to fit into the range of (0.01 * qibo_time, 100 * qibo_time).

  assert 1e-2 * qibo_time < quimb_time < 1e2 * qibo_time

E assert (0.01 * 1.6729983501136303) < 0.0031228289008140564

tests/test_qasm_quimb_backend.py:59: AssertionError
----------------------------------------- Captured stderr call ------------------------------------------
[Qibo 0.1.10|INFO|2023-02-16 16:49:43]: Using qibojit (cupy) backend on /GPU:0
------------------------------------------- Captured log call -------------------------------------------
INFO qibo.config:init.py:85 Using qibojit (cupy) backend on /GPU:0

[alecandido]

After merging, pytest hit an error below. Seems the cause is that quimb_time is too small when , failing to fit into the range of (0.01 * qibo_time, 100 * qibo_time).

This is an extra condition I added, not to leave times unused. It was a rough attempt, but I considered unlikely to fail.
@scarrazza should I simply drop it?

EDIT: I believe it might only fail on a machine with an available GPU, e.g. not mine, but that is an interesting information: why Qibo is so slow with cupy backend, if Quimb is so fast?