Automated release script - GitHub project repository status report

When creating a release, we now have the `make release` target. This takes care of a lot of code things, but I realize there is Github API to handle repo things. That target is here:

https://github.com/AcademySoftwareFoundation/OpenTimelineIO/blob/b1931689dc2722396733d6830e928be614f0856a/Makefile#L259

This is from our release process wiki:

1. Accept or reschedule (to a later milestone) any open PRs assigned to this milestone:L https://github.com/PixarAnimationStudios/OpenTimelineIO/pulls
2. Check the Github Actions status and make sure there are no failures (`make lint`, `make test`): https://github.com/AcademySoftwareFoundation/OpenTimelineIO/actions
3. Going through the github issue tracker: https://github.com/PixarAnimationStudios/OpenTimelineIO/issues
* Open issues from this milestone should be closed or resorted to later milestones
* Open issues with no milestone, make sure that none of them got done this milestone and should be closed (or that they belong in the next milestone)
* Closed issues that have no milestone (make sure they get sorted into the correct milestone, likely just added to the current milestone)
* Closed issues from the next milestone (to make sure they shouldn't be added to this milestone)

...

* Create a milestone for the version past the current one. This has been useful to sort things into "stuff we're doing now, stuff we're doing soon, and stuff we're doing someday" (current milestone, next milestone, 1.0/next major version milestone).

It would be cool to have a script that:

- [ ] queried the GitHub action status on Head and made sure the build was clean
- [ ] Gave a report of Issues/PRs assigned to the milestone that are still open
- [ ] Closed issues that were closed since the last release but have no milestone
- [ ] And creating a milestone for the version past the next one if it doesn't exist (for example, if creating version 0.16, make sure that milestone 0.17 is there)

Actually closing the milestones, or reshuffling open issues is probably left to human intervention, but having a dashboard to look at rather than changing a bunch of things in the issues interface would help clarify the task.

Start with the make release target in Makefile and compare it with the release process wiki linked in the issue. Review the GitHub Actions status and milestone, issue, and pull request workflows described there. Done means a report covers build status, open milestone items, unmilestoned closed issues, and creation of the milestone after the next version.

Written by the indexing model from the issue text.