Prepare 0.23.0 release

[mtreinish]

Summary

This commit prepares the 0.23.0 release, this involves 2 steps first changing all the version numbers to 0.23.0 from 0.23.0rc1 and secondly updating the release notes to prepare them for publishing.

One key thing to note is that this PR removes the 0.22.0 release notes. This is because for the 0.22.0rc1 tag we neglected to move the release notes to a separate directory. So when we did that for the 0.22.0 final release we had to forward port this back to main so that any backports to stable/0.22 would be backportable (see #8901). However, this causes reno to detect all the 0.22 release notes are incorrectly as part of the 0.23.0 development series. To fix this the simplest path forward was to remove the 0.22.0 release notes from the 0.23.0 branch (as in this PR).

Details and comments

TODO

• Remove backported release notes
• Review and edit all 0.23.0 release notes

[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
• @ajavadia
• @enavarro51
• @ikkoham
• @levbishop
• @manoelmarques
• @nkanazawa1989
• @t-imamichi
• @woodsp-ibm

[Cryoris]

Some comments on the releasenotes 🙂

[mtreinish]

I've finished my first pass going over the release notes, so this PR should be ready to review now.

[kevinhartman]

Just a review of prepare-0.23.0-release...yaml.

[jakelishman]

Mostly typos, there's like 3 actual comments.

[jakelishman]

Technically you're right to include this, but in practice, label is something we're going to want to heavily de-emphasise in the move to singletons. This gate probably won't end up as a singleton, but even so, we maybe want to drop this bit?

Suggested change

	being ignored. If you need to assign a ``label`` to an
	instance of :class:`~.MCMT` or :class:`~.MCMTVChain` you should convert
	them to an :class:`~.Gate` instance with :meth:`~.QuantumCircuit.to_gate`
	and then assign the desired label to :attr:`~.Gate.label` attribute. For
	example::
	from qiskit.circuit.library import MCMT, XGate
	mcmt_circuit = MCMT(XGate(), 3, 2)
	mcmt_gate = mcmt_circuit.to_gate()
	mcmt_gate.label = "Custom MCMT X"
	being ignored.

[mtreinish]

The example wasn''t in there originally and I was struggling to visualize exactly what a user doing MCMT(..., label="") was meant to do with just the text which is why I added the example. I don't really feel strongly one way or the other though, I think this is a definitely and edge use case. But I just generally feel upgrade notes should state the alternative if one is available (or the justification why one isn't).

[jakelishman]

I'm happy to leave this on the basis of providing complete release notes tbh.