Handle Qiskit release notes structure correctly to split out the notes by version

[Eric-Arellano]

Follow up to #294 and #281.

@frankharkins found that it works well using the HTML generation script. A key change from Qiskit itself is we have one page per minor release, like release-notes/0.45. We need to make two improvements:

1. Restructure Qiskit/qiskit to have one release note file per release for future releases. Whereas right now they have the file release_notes for all notes from Qiskit 0.45 forward
2. Update our script updateApiDocs.ts to handle new release notes automatically, including the wonkiness of the prior release note files (legacy_release_notes.html).

[Eric-Arellano]

I'm thinking that the simplest solution will be for Qiskit to continue having only a single file release_notes.rst. Note that we removed legacy_release_notes.rst already.

Then we have the Qiskit devs configure Reno so that release_notes.rst only has the release notes for the current version of that branch, such as 1.0 vs 1.1. That will simplify updateApiDocs.ts because it only needs to convert release_notes.rst into a single file under the release-notes/ folder for the current API version. That is, it doesn't need logic to parse the file and extract out the relevant version from the file; the file already only has what is relevant.

We need Qiskit devs to be okay with the plan, since they'd need to tweak the versions listed in release_notes.rst with releases. I'll present this plan to them at the weekly meeting next week.

cc @arnaucasau and @frankharkins

[Eric-Arellano]

We decided in the Qiskit dev meeting after talking this over with @ElePT, @jakelishman, and @mtreinish that the changes should happen in this repo, not in Qiskit/qiskit. They value building the historical release notes in their local builds more than I realized.

They also do sometimes change prior release notes, such as fixing typos. It's important that Qiskit/documentation pulls in those changes, even if the release notes changed don't correspond to the current version of the docs we're building. For example, if we're building 1.1 docs, we should still see if there were any updates to 1.0 release notes.

So, this issue now tracks us improving updateApiDocs.ts to properly handle release notes for Qiskit. It will still only look for the file release_notes.html, but it needs to properly split out the file into its distinct minor releases, such as by using the logic from the PR description in #346.