Added tool for building release-notes before dev to main merge. Closes #842

[jcob-sikorski]

Creates list of PR titles from previous release until now aggregated in chronological order and added to the release RST file.

Prior to merge to main, it creates a list of PRs, titles only, that have been merged into dev from previous_release until now, and opens a new PR (called Release Notes PR)

Since it's a PR, the maintainer merging it can look at it, tweak some things if they need to, then merge it into dev right before they merge dev into main and BAM! Release notes will be published.

Maintainer must manually launch a "create release notes" github action via a manual trigger (change setup.cfg file)

[daxpryce]

Okay, so a bunch of inline comments - moving stuff around and targeting it closer to our release process.

The main problem we have is using setup.cfg on dev (or main!) as the trigger. The ONLY time we want release notes is when dev is merging into main, and it has to be created PRIOR to that. Rather than try to trigger on file changes, I say remove all triggers - then @bdpedigo or myself can just know "oh we need to do a release now, we should manually run the action" - which we can do - from the actions page.

So let's change it to be a manual process, and you can open the PR against the dev branch. Prior to release, us release managers will know "we're going to cut a release today, so we'll execute the action to generate the release notes, look over the generated changes, reword some things or cluster things (for instance, we won't need 8 entries for "fixed mypy hoopajoop" or "sphinx is broken again because it's always broken for us I swear on me mum", we can just collapse them down to "Type hinting and documentation generation fixes".)

This is still super useful as a starting point and I'm really pleased with this approach! Let's just make a few of the inline changes mentioned and get rid of the trigger in favor of a manual initiation process, and then I think we can probably take a deeper look at whether we can gather the user initiating the action being responsible for the commit email and name and whatnot when you go to make the commit and push for the PR - that way it's not a bot doing it, so much as a bot doing it on my or @bdpedigo's behalf).

Thanks so much for taking a stab at this!

Edits: tweaks to wording

[jcob-sikorski]

Everything now works as expected with changes you proposed:

• the entire process is inside a single python file
• moved build_release_notes.py to github/scripts
• triggered manually
• new release notes prepended to existing/nonexisting release notes
• writes only PR titles

[bdpedigo]

@daxpryce do you want to re-review?