Create qem methods module

[jordandsullivan]

Issue Description

Currently the top level directory of mitiq is a bit hard to parse. For instance, a new user would not immediately know which modules are actual implementations of QEM methods and which are runners, interfaces, or utility modules.

With the existing directory structure, a new user or contributor looking at the code base would have to click through cdr, ddd, pec, pt, qse, raw, rem, and zne to determine that all of those except raw are QEM methods:

Proposed Solution

Refactor the existing mitiq codebase slightly to create a new module named mitiq.qem, and create a method within that module to retrieve all available methods. One advantage to this (beyond neatness) would be to clarify which modules are actual implementations of QEM techniques and which are runners, interfaces, or utility modules. This may help new users and contributors understand the codebase more easily, especially given the use of acronyms as a naming convention for QEM methods. It would also be a bit more convenient for #2244 to have a single module to query where all the QEM methods live.

In this version, the top level of the mitiq would look like this:

benchmarks calibration executor interface observable qem tests init.py _about.py _version.py typing.py utils.py

where the qem module contains cdr ddd pec pt qse rem zne

The raw and shadows modules could remain as separate, top-level modules or go in qem.

Additional References

N/a

[purva-thakre]

We'll probably discuss this issue during the March 29 community call.

Personally, I think Pauli twirling is not a QEM method. It's a noise-tailoring technique. So, the qem module could also look like below:

cdr ddd pec noise_tailoring qse rem zne

pt could be moved into the noise_tailoring module. This could be useful if we decide to add another noise-tailoring technique like Clifford twirling in the future.

[nathanshammah]

@jordandsullivan I like a lot the idea. The only caveat for me would be keeping the import without the "methods." bit (which I guess can be addressed in that init file).

[nathanshammah]

@jordandsullivan assigning this to you as discussed, and adding it to the current milestone as also tightly related to https://github.com/unitaryfund/mitiq/issues/2244.

[purva-thakre]

Since we had a discussion about this issue being a breaking change, I think it might be better to wait until #2253 is resolved as this will also be another breaking change we introduce a couple of versions later.

[natestemen]

2253 should not introduce any breaking changes. Just provide a new API for using our existing techniques.

[purva-thakre]

@natestemen API changes are not considered breaking changes? Very interesting!

[natestemen]

API changes generally are breaking, but API additions should not break existing workflows.