Improve exception expressiveness

[nelimee]

Is your feature request related to a problem? Please describe.
For the moment, the code base only include one exception, TQECException, that is raised with a descriptive error message whenever an exception need to be raised. It might be beneficial to split that unique exception into several more expressive ones.

What is you opinion on that? If you agree, what should be, in your opinion, the rule to decide whether a new exception inheriting from TQECException should be included or an existing generic exception (such as TQECException) should be used?

[Gistbatch]

I suggest that we have exceptions for multiple situations.
Parsing the description string is easy for a user but not helpful when catching specific exceptions programmatically.

Some possible use cases:

• InvalidCodeException: The user has specified an invalid error correction code or something similar
• FormatException: Exceptions when switching between libraries occur, e.g., TQEC frontend, stim, cirq, collada ...
• BrokenAssumption: If one of the assumptions throughout the code is not fulfilled, e.g. midline cannot be computed