Deprecate BlueprintCircuit based circuit usage

[woodsp-ibm]

Summary

Closes #931

Move away from BlueprintCircuit based circuit usage

Todo:

• Add a release note
• Update notebooks

I figured I'd check in the code changes ahead of doing the above just in case any alterations to what was done were wanted.

Details and comments

This updates machine learning to move away from BlueprintCircuit based classes and use instead the circuit library functions which create similar circuits but which cannot be updated the same way once created e.g num_qubits is fixed at creation time.

In ML here were RawFeatureVector and QNNCircuit both of which are subclasses of BlueprintCircuit, These I deprecated but they can still be used and algorithms still accept the. Their "replacements" are raw_feature_vector and qnn_circuit methods which cannot be updated for num_bits etc similarly now to the qiskit circuit library functions.

raw_feature_vector just returns a circuit - RawFeatureVector had a num_qubits getter, which by virtue of being a QusntumCircuit it still has, but the getter to get feature_dimension no longer has any way to specifically get this but its easy to compute as its 2 ** num_qhbuts.

qnn_circuit, this returns a circuit and the parameters for the underlying feature map and ansatz so they can be passed into a QNN, eg SamplerQNN directly. It performs the compose but also creates circuits based on number of qubits etc as before so since it was a bit more that a simple composition function I kept it. You cannot get at the underlying anstaz or feature map circuits like you could with the QNNCircuit getters and while I could have passed those back as well I kept it to what the xxxQNN needs which is th circuit and which parameters are used for input and weights. If someone were to need those for any reason they could make their own composition like in fact the example in the docs for SamplerQNN & EstimatorQNN show.

The other aspect I updated is the util method derive_num_qubits_feature_map_ansatz in adjust_num_qubits.py. Since it seems to be a public method I altered it so it does either BlueprintCircuit based circuits like it did before, the default, or if you set a new argument to True then it uses the library function equivalents,

Evidently any BluePrintCircuit based/using code will need to be removed later but for now it all should work as it did before but code will use the functions where it did not seem to be a compatibility concern as such.

[coveralls]

Pull Request Test Coverage Report for Build 15491457210

Details

• 45 of 46 (97.83%) changed or added relevant lines in 8 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.04%) to 90.865%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit_machine_learning/circuit/library/raw_feature_vector.py	11	12	91.67%

Totals
Change from base Build 15481452867:	0.04%
Covered Lines:	4526
Relevant Lines:	4981

---

💛 - Coveralls

[edoaltamura]

Thanks very much for this update Steve! I made some suggestions in the code. The plan seems to remove the class versions of the circuit library instances in 0.9.

[woodsp-ibm]

Thanks very much for this update Steve! I made some suggestions in the code. The plan seems to remove the class versions of the circuit library instances in 0.9.

I would not say remove, rather deprecate their usage, In examples, tests, notebooks the intent was to use the functions and only the class based ones minimally in unit tests to make sure things still work there. So code still works with both but one should be moving away from the class based ones over to the functions - whether its the Qiskit library ones or the functions I created for the class based library circuits in ML here.

At some point down the road then yes they would be removed, but that's some unknown future version in my mind, not 0.9

[woodsp-ibm]

I see you merged this, My intent, as per the todo in the PR at the start was to add a release note and update the tutorials to use functions where needed after the fundamental code changes I did had been seen, and agreed with, just in case. Maybe its my bad that I did not do this as a Draft. Still I can always do another PR of course, we do need a release note to talk about the deprecations here and it would be better if the tutorials were not using deprecated code. Maybe I'll do the release note in PR on its own so as that is at least that can be here too and tutorials can be looked at after.