New CD workflow

[TwistedTwigleg]

Description of changes:

Moves Python CD workflow to new method and adds version stamping to the Python V2 SDK so the VERSION file's value is always the latest release version.

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[graebm]

I've got an idea that could make this more graceful than this approach from aws-crt-cpp

This approach is:

• Team member uses Github Release webpage (pick new number, pick title, pick notes (usually autogenerated))
• Release workflow notices release, makes commit with version numbers, and then edits tags and releases to reflect that new commit
• PROs: we get to use the Github Release webpage
• CONs:
  • it's weird that the script edits tags/releases. There's a chance some external user or bot queries the latest release or tag in the moments before they're deleted and replaced by new ones, and ends up getting the wrong commit
  • There's also a chance someone names the release tag wrong (forgets the "v", or sets the wrong value for MAJOR.MINOR.PATCH
  • Also people frequently check the wrong "pre-release" and "latest-release" checkboxes since we're not 100% consistent across repos on whether these should be checked or not

Here's an alternate idea I've had in the back of my head:

• We make our OWN webpage that team members use to create releases
  • We can use Github workflows. If you manually run a workflow, the inputs become the webpage form elements that the user needs to fill out (here's a youtube video showing what I mean. So we could have:
    • script properly increments version based on whether this is a MAJOR, MINOR, or PATCH release (or maybe don't even give the option for MAJOR since that would be a huge mistake to make)
    • user could manually type in title for release
    • we could use the gh release --generate-notes option to automatically fill out the notes
  • Workflow commits new version file to main
  • Workflow creates release & tag based on that new commit
  • PROs:
    • always gets the version string and "pre release" and "latest release" correct
    • doesn't "edit history" by deleting and replacing the tag and release
  • CONs:
    • This would be new and different. We'd have to figure it out
    • What if someone doesn't know about the new way to make release for this repo and does it the old way? Maybe it doesn't matter, since the release pipeline wouldn't run as a side-effect of a new github release, it would run due to explicit invocation from the new workflow

[TwistedTwigleg]

Thanks! Merging into main...