chore: add v12.2.0 release notes

[aleclarson]

The release notes for v12.2.0, a work in progress. I've created a release-notes branch, which this PR targets, so I could open a PR tracking my progress and inviting collaboration. This should help keep the process open and transparent. These release notes will also exist in the GitHub Releases section upon completion.

What's needed:

• More/better code examples (edit: Now that we link to the docs, this isn't as big of a deal. Just make sure the example previews the core functionality.)
• Check for missing commits (excluding chore commits)
• Ensure all PR/commit links are inside the headings
• General proof-reading and refinement

Long-term solution

I used this script to generate the initial draft. The generated draft saved a lot of time, but I've since edited it quite a bit. I think there's still room for improvement in that script, so less editing is needed in the future. Specifically, including an example of desired output would help a lot, I think.

[MarlonPassos-git]

Hey @aleclarson, do you intend to keep a {version}.md file for all future versions?

[aleclarson]

@MarlonPassos-git Yeah that's the plan. Why do you ask?

[MarlonPassos-git]

@MarlonPassos-git Yeah that's the plan. Why do you ask?

And I was thinking that over time it might get a bit messy having a large number of {version}.md files at the root of the project. This isn’t something I usually see in projects; they typically group them into a documentation folder or something similar.

[aleclarson]

Oh I think you misread what I wrote up top. 😄 As you can see, this PR is targeting a release-notes branch, which is where they'll be kept.

[aleclarson]

Just now, I've refined all of the sections from the beginning until isRegExp (which still needs refinement itself). If anyone wants to contribute to this PR, please use the same formatting that I've gone with in those sections. To see how I've refined those sections, you can take a look at my recent commit.

The basic guidelines are:

• Section headings should briefly describe a function's main purpose.
• Section headings should not include the function name.
• Section headings should have a link to the PR/commit included at the end.
• The first sentence of each section should include the function name.
• The first sentence of each section should not repeat the section heading.
• If multiple details (beyond the first sentence) must be explained, split them into a bulleted list.
• If a function has multiple, distinct, non-obvious parameters, include a Parameters: subsection listing the name (wrapped in backticks) and purpose of each parameter. When a parameter is optional, include ? at the end of its name.
• Include links to the docs, source code, and tests at the end of each section.

[aleclarson]

I've done more work on this today. I'm down to line 782!

[MarlonPassos-git]

🥳