When nightly builds succeed, write any key release notes updates to a changelog

[e-belfer]

Is your feature request related to a problem? Please describe.
Right now, we only publish our release notes once a quarter. With the adoption of regular nightly build release deadlines, we ought to have a way to communicate the following to our users:

• Today's nightly builds contain a new feature, new data, or a bug fix
• Looking back, when did different changes get merged in (e.g., if I'm working from a two-day old nightly build download, do I need to redownload the newest data?)

Note that much of this information is in our release notes, but they do not convey and sense of time in relationship to the nightly builds. This information cannot be conveyed through the closure of Github issues, as there is generally a lag of at least one day between PR merges and the data being actually available (see, e.g. #3677). So, ideally, we could communicate how changes in our release notes appear in the nightly builds.

Describe the solution you'd like

• In build-deploy-pudl.yml or as a separate job, if the nightly build succeeds, and if the release notes have changed, we process a changelog of the release notes. Any newly added lines to the most recent section of the release notes should get added as bullet points to a centralized release-log.txt or release-log.rst file, also stored in the builds-catalyst-coop GCS bucket. We may have to remove some of the .rst formatting as well if we don't use an .rst file
• The log should make it clear what the change was, and which nightly build the change was published as part of. E.g., an entry might look like:

  • 2024-07-26: Added EIA 923 early release data from 2023. See issue 3719 and PR 3721

• After this is working as expected, we could hook this release log up to some kind of notification feature to give people regular updates about updates to our (e.g., an email list or RSS feed, an X bot, etc.).

Challenges

• Right now, we don't publish the release notes as part of the nightly builds, only the data itself. So, we'll need to figure out how to identify the release notes of the last published data, and compare them to the current release notes, e.g.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

• We create a release log but manually update it - we will forget to do this regularly.
• We trigger this from Github when the release notes are updated in main - this will be out of sync with when the actual nightly builds pass, as any failure could create a 1+ day delay between merging in the release notes change and the data itself landing in the nightly builds.