Replace PauliSumOp with SparsePauliOp

[mrossinek]

What should we add?

We need to replace all public API occurrences of PauliSumOp with SparsePauliOp.

• in cases where the type is a function input, for the transition period we need to replace it with the union of the two and handle it accordingly internally

• in cases where the type is an output we also need to make it the union. However, we cannot simply return whatever we want. I suggest that we add a setting to qiskit_nature.settings which can toggle between the two cases. In the next release, we still default it to return PauliSumOp but have it raise a DeprecationWarning that the default will change to SparsePauliOp. This would be similar to how we handled the dict_aux_operators transition.

[Anthony-Gandon]

This change goes in parallel with a transition from the z2symmetries of opflow for PauliSumOp to the z2symmetries of quantum_info for SparsePauliOp Ideally, we would make the two transitions simultaneously.
Similarly, the qubit_converter heavily relies on the PauliSumOp but will be replaced by new mappers which will be based on SparsePauliOp.
Last thing, I wanted to mention that multiple tests use the == / assertEqual for operators which work for PauliSumOp but not for SparsePauliOp because of the Pauli's ordering:

from qiskit.quantum_info import SparsePauliOp

qubit_op = SparsePauliOp.from_list(
    [
        ("IIXZ", -1.0537076071291125), # 1
        ("IZXY", 0.393983679438514), # 2
        ("ZIYY", -0.39398367943851387), # 3
        ("ZZIZ", -0.01123658523318205), # 4
        ("XXYI", 0.1812888082114961), # 5
    ]
)
qubit_op2 = SparsePauliOp.from_list(
    [
        ("IIXZ", -1.0537076071291125), # 1
        ("ZIYY", -0.39398367943851387), # 3
        ("IZXY", 0.393983679438514), # 2
        ("ZZIZ", -0.01123658523318205), # 4
        ("XXYI", 0.1812888082114961), # 5
    ]
)
print(qubit_op.equiv(qubit_op2)) # True
print(qubit_op.__eq__(qubit_op2)) # False

I believe this will lead to additional changes

[mrossinek]

Thanks, Anthony! @manoelmarques did indeed start looking into this and made the same observations. We put this on hold until the work on #967 is completed 👍