Time Evolution Framework with primitives.

[dlasecki]

Summary

This PR moves time evolution interfaces and classes to a new location where primitive-enabled time evolution algorithms will reside. It also limits the use of opflow objects.

Closes: TODO

Details and comments

• Release notes.
• Deprecation messages. @manoelmarques

[qiskit-bot]

Thank you for opening a new pull request.

Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient.

While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone.

One or more of the the following people are requested to review this:

• @Qiskit/terra-core
• @manoelmarques
• @woodsp-ibm

[coveralls]

Pull Request Test Coverage Report for Build 3048002047

• 79 of 81 (97.53%) changed or added relevant lines in 11 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.02%) to 84.339%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/algorithms/time_evolvers/imaginary_time_evolver.py	7	8	87.5%
qiskit/algorithms/time_evolvers/real_time_evolver.py	7	8	87.5%

Totals
Change from base Build 3047917829:	0.02%
Covered Lines:	57960
Relevant Lines:	68723

---

💛 - Coveralls

[Cryoris]

Some minor comments otherwise LGTM 👍🏻

[woodsp-ibm]

This PR moves time evolution interfaces and classes to a new location

This is creating new interfaces here based on a copy of the originals right (not moving them perse). The originals, in evolvers, of these 4 files need to be pending deprecated - along with trotterization trotter_qrte as these were the only files released (basically what was added by #7411) that are presently in evolvers in main.

Should we do trotter_qrte in this same PR since that would span all the code which has been released (code added by VarQTE and PVQD, since it has not yet been released, can be moved).

At this point I think we should add a time_evolvers link to algorithms init so as to start on the documentation. We may need to update the init file here so that they get documented too. Since we need to maintain evolvers they cannot collide for now what was already imported/documented directly in algorithms rather a user will explicitly have to import from time_evolvers until such time as the originals are removed and we can allow import back at the algorithms level of these new ones too. Though arguably if we also added Time to the class names we could have them at algorithms level too - e.g EvolutionProblem -> TimeEvolutionProblem, RealEvolver -> RealTimeEvolver etc. Naming thus would arguably fit better with having these as time evolvers.

[woodsp-ibm]

@dlasecki Did you have any feedback to this comment from above

At this point I think we should add a time_evolvers link to algorithms init so as to start on the documentation. We may need to update the init file here so that they get documented too. Since we need to maintain evolvers they cannot collide for now what was already imported/documented directly in algorithms rather a user will explicitly have to import from time_evolvers until such time as the originals are removed and we can allow import back at the algorithms level of these new ones too. Though arguably if we also added Time to the class names we could have them at algorithms level too - e.g EvolutionProblem -> TimeEvolutionProblem, RealEvolver -> RealTimeEvolver etc. Naming thus would arguably fit better with having these as time evolvers.

[dlasecki]

@dlasecki Did you have any feedback to this comment from above

At this point I think we should add a time_evolvers link to algorithms init so as to start on the documentation. We may need to update the init file here so that they get documented too. Since we need to maintain evolvers they cannot collide for now what was already imported/documented directly in algorithms rather a user will explicitly have to import from time_evolvers until such time as the originals are removed and we can allow import back at the algorithms level of these new ones too. Though arguably if we also added Time to the class names we could have them at algorithms level too - e.g EvolutionProblem -> TimeEvolutionProblem, RealEvolver -> RealTimeEvolver etc. Naming thus would arguably fit better with having these as time evolvers.

Hello, I did not think much about it beforehand but I liked your idea about adding Time to class names. It will be more consistent with the package, more explanatory and a clearer differentiator from old classes. I suppose we can accept slightly longer names due to this change. I went ahead and updated classes according to your idea, including linking them to the algorithms init file which should solve the missing documentation.