Decouple local and remote operations in release script and add tests

Per Madrid discussion, we'll rewrite the release script. And let's consider if it could be used in our other repos too (e.g. Jubilant), particularly for generating correctly formatted changelogs (this implies decoupling changelog / etc logic from Ops specific package version bump logic).

New UX:

- Run the script.
- It bumps the versions (prompt with simple guess, user can correct).
- It writes the changelog (generate locally, don't pull from a draft release).
- It may bump the tools doc.
- Finally it creates a PR (draft) (CLI option not to do that).
- User finalises PR, write release notes in description, PR is reviewed and merged.
- Either push the green button yourself, or (stretch goal AKA leave out: run the script and it auto populates the draft release and copy pastes in the changelog (from the changelog) and the notes (from the merged PR if we're not checking the notes in).
- Run the script to post-release-bump all the versions, same flow as 'run the script' but simpler.

Move it to a directory, add tests:
- `.github/release/release.py`
- `.github/release/test_release.py` (unit-like)

One module, but structured according to operations (version bumping, local interaction, draft release, PR).

Generate the changelog locally (don't pull it from a draft -- creating the draft can happen at the end).

Draft the release notes in the PR for one place review. Written by the person who runs the script. Not written in flow of running the script.

---

Old issue description:

Per discussion in #2199 ([comment](https://github.com/canonical/operator/pull/2199#issuecomment-3634444335)), doing the following would make testing, updating, and maintaining the release script easier:
- decouple the flow of the local-only operations (choosing the new versions and applying them both pre and post release) from operations on the Github remote (creating a draft release, creating PRs)
- add unit tests for the cleanly decoupled parts
- add flag or prompts to run local operations only for easier almost-end-to-end testing