Improved SamplingVQE algorithm implementation

[Itaborala]

Integrating a re-implementation of the SamplingVQE class, together with the BasisProtocol and AmplitudeProtocol made on commit db2b996

This would also lead to an improved structure of the VQHAlgorithm class, allowing for modularity. A few considerations from @schwaeti during email exchanges:

• The QUBO and the Isisng problem should be implemented as separate classes. (For legacy compatibility, a QUBOIsing problem class may also be necessary)
• Writing a SparsePauliOp is problem specific - as a result, the Problem class implementations now would have an evalutate function specific to that problem.
• A separate implementation for SamplingVQE and general VQE is necessary.
• An improvement of the QuantumHardwareInterface class would lead to each provider having their own Sampler class

Tasks:

• Rewriting the Protocol classes for adequate names
• Include Greedy and VQE
• Writing qubo_to_ising
• Write IsingProblem
• Rewriting the old VQEAlgorithm and replace it with the new implementations, preserving functionality (vqe/vqe_algorithm.py)

[Itaborala]

A questions that I still have (should this be an issue): what is the best structure for the implementation of different encoding schemes?
Each problem may have it's own encoding strategy (and probably ansatz), but these encodings would potentially be shared along several problems (is this a 'bridge' software design pattern? or a 'converter'? something else?).
I am mentioning this, because in the new QUBO class (commits abda719 and 60261bc), the function qubo_to_array is incorporated in the Problem class, instead of the Protocol class (as it should, because it is problem specific). However, the encode method was not implemented on the new BasisProtocol and AmplitudeProtocol (commit db2b996), which is necessary for the integration.

In result, this is starting to look similar to the VQHMapper class, that needs to call a specific method that was implemented for a specific sonification strategy. but the method it sees and calls is from a parent class called SonificationInterface.map_data() (see map_data and VQHMapper)

Sketching a solution: In (soon-to-be-released) v0.3.0, the VQEAlgorithm class calls a VQHProtocol.encode() method (see here). In turn, this method could contain a getattr function, that gets one of the encoding strategies that can be applied to the problem in question. This would also require a dictionary containing a description of the problems and the mehtod they use and need.

[Itaborala]

Discussion with @schwaeti :

• The Prococol class may need to be dropped in the future. is this really needed?

A two-step process for the integration:

• The names of the new protocols are different. The new AmplitudeProtocol implements marginal distributions. The new BasisProtocol does what the old Amplitude Protocol is doing. First step is to simply swap those.
• Then, we solve the new naming problem. Is this one-hot? is this basis? is this amplitude? (this belongs to Moving and renaming classes, functions and methods #8 )

[Itaborala]

For the Algorithm class:

• By incorporating the VQHProtocol.encode() method into the VQHProblem.load_data(), we don't nee to call the encode method anymore from the VQHalgorithm classes. The problem will be loaded in the expected format, ready to be used. This should then be stored in a common attribute name VQHProblem.instances (when there is more than one problem defined in the file). As a result, the VQHAlgorithm.variables_index attribute will be deprecated. Remove Deprecated Code #6