Allow constructing a SparsePauliOp from a SparseObservable

[Cryoris]

What should we add?

quantum_info objects can typically be constructed from one another, e.g. we can do SparseObservable(sparse_pauli_op_type), Operator(sparse_pauli_op_type) or SparsePauliOp.from_operator(operator_type). It would be nice to extend these operations for SparseObservable. In particular constructing a SparsePauliOp from a SparseObservable would ease the transition to this new type -- doing the construction for an Operator is more of an optional convenience (albeit possibly leading users onto inefficient paths).

[jakelishman]

Constructing SparsePauliOp from SparseObservable can exponentially explode the memory usage - that's one of the reasons SparseObservable needed to exist. We should still allow it, but it possibly shouldn't be an allowed default conversion in the default constructor because it's dangerous.

All the work for Operator is tracked by #13389.

[Cryoris]

Oh right, the Operator case will already be done with the to_matrix method 👍🏻

Regarding the exponential overhead: yes that's right, maybe we'll just add a method instead, SparsePauliOp.from_sparse_observable instead and include a runtime warning in case we'd need to construct too many Paulis for the projectors.