[Feature] Simulator engines Api for Pulser backend

[Doomsk]

Currently, pulser backend only presents a simple case using QuTiP. Ideally, the simulator/emulator engine should be part of the Model options, and an API class to be provided for template and abstraction purposes to implement each engine calls.

For example:

model = Model(
    register=AllocQubits(...),
    ...
    settings={
        "diff_mode": False,
        "eom_mode": True,
        "many_qubits": False
    }
)

# the model above should invoke QuTip simulator with EOM on pulses

model2 = Model(
    register=AllocQubits(...),
    ...
    settings={
        "diff_mode": True,
        "many_qubits": False
    }
)

# while this one above should invoke pulser-diff

model3 = Model(
    register=AllocQubits(...),
    ...
    settings={
        "many_qubits": True
    }
)

# and this should invoke EMU-TN, for instance

---

@awennersteen pinging because we discussed this at some point so you can follow up on it.
@kaosmicadei @dominikandreasseitz @Roland-djee @jpmoutinho @chMoussa pinging for awareness.

[kaosmicadei]

What happens if someone wants to compile the first model using EMU-TN?

[kaosmicadei]

model = Model(
    register=AllocQubits(...),
    ...
    settings={
        "diff_mode": False,
        "eom_mode": True,
        "many_qubits": False
    }
)

Wouldn't that require the user to know the existence of the EOM and its purpose?

Is that like a more compile flag than a Model flag?

[Doomsk]

model = Model(
    register=AllocQubits(...),
    ...
    settings={
        "diff_mode": False,
        "eom_mode": True,
        "many_qubits": False
    }
)

Wouldn't that require the user to know the existence of the EOM and its purpose?

Is that like a more compile flag than a Model flag?

@kaosmicadei the compiler should decide whether to use EOM based on the device coherence time and length of the pulses, etc. Unless the user somehow specifies such a thing during the compile with extra options, it's up to the compilation to organize it.

Of course it will be propagated to Model and beyond so the backend can the properly addressed with those options.

[kaosmicadei]

the compiler should decide whether to use EOM based on the device coherence time and length of the pulses, etc. Unless the user somehow specifies such a thing during the compile with extra options, it's up to the compilation to organize it.

As a user, my point is that if I want to benchmark the same sequence with and without EOM, I cannot use the same Model.

If the user has no knowledge about it, then the backend should make such a decision. But it shouldn't be a task for the expression compiler to handle. Instead, it should be passed as an option to the backend.compiler.

My point here is to define what should be used as Model flag and compiler flag.

The model should carry enough information to produce a sequence, not how to do it.