Rename QITE → DB_QITE to support multiple QITE methods

[Sam-XiaoyueLi]

This PR proposes to free up the name QITE if other imaginary-time evolution methods would at some point be added to Qrisp.

1. It renames the existing QITE implementation to DB_QITE (Double-Bracket Quantum Imaginary-Time Evolution) to clarify that it’s one specific QITE variant.
2. This change makes room for a top-level QITE method which handles the dispatch to potentially other approaches via the procedure_type = argument
3. By default the procedure_type=db_qite and so the PR is backwards compatible i.e. previous QITE calls will execute DB-QITE as before.

[marekgluza]

Suggested change

	To anticipate other methods implementing QITE
	To anticipate other methods implementing QITE.

[positr0nium]

Thats an interesting idea 🤔😊 I really like the possibility to directly exchange QITE strategies for comparison. However to make this modularity true, I think it would be good if we condensed the interface a bit better. Having just **kwargs that could be anything is very general but also allows implementing the same arguments with different naming, which would destroy the original purpose (modularity under QITE strategy exchange).

It could be helpful to review alternate QITE strategies to understand which arguments always appear (qarg seems to be such an argument). I could imagine that there always needs to be some kind of access to the Hamiltonian? Is this access usually given in the form of a simulation procedure?