Refactor new code for GitHub releases

[vivus-ignis]

What would you like to be added:

• OOP style for the code in github module

Why is this needed:

Suggestions from @NotTheEvilOne:

• do not use s3_artifacts._bucket property, use bucket (without underscore) instead 189 refactor new code imported from gl workflow scripts #232

• add support for semantic versioning Semver support #219

• use commit_id parameter for CName constructor 189 refactor new code imported from gl workflow scripts #232

[NotTheEvilOne]

Here's the complete list of changes requested originally:

• Please replace low-level code with code provided by apt* Python packages.
• While we are working with GitHub API for this executable I would recommend to leave it separate to any "generic" GitHub tooling we might need. Therefore the executable should be called something like gl-github-release and call a gardenlinux/github/release_main.py entrypoint.
• Please be aware of best-practices for Python imports. First the standard library (alphabetically sorted), afterwards third-party libraries and then relative ones. Furthermore the code now resists in the python-gardenlinux-lib repository, so all gardenlinux.* imports should be relative ones.
• This file (github/__main__.py) needs refactoring. There are too many generic / helper functions doing various things needed for later release content creation.
• Does it make sense to add this code (GitHub release creation) in a generic way to e.g. GardenLinuxRepo?
• Context managers should be used only as long for locking a file as it's needed. Class initialization and return may stay outside.
• This looks like another hardcoded file name (.github_release_id). Please consider moving it to a constant or something that can be configured.
• This code should be replaced by a third-party Python package providing support to talk to the GitHub API. If needed it may be encapsulated by one or more classes added to gardenlinux.github.
• I'm still not sure if flavors.yaml should be "checked" out here (gardenlinux.github).

[NotTheEvilOne]

Additional task:
Release page generation fails with error github.GithubException.GithubException: Validation Failed: 422 {"message": "Validation Failed", "errors": [{"resource": "Release", "code": "custom", "field": "body", "message": "body is too long (maximum is 125000 characters)"}], "documentation_url": "https://docs.github.com/rest/releases/releases#create-a-release", "status": "422"}.

[NotTheEvilOne]

There has been the idea to access a release asset called e.g. cloud_images.md or packages.md to remove specific sections from the release notes for GitHub limiting reasons (see #318, #319).

With supported GitHub API this would mean to:

1. Create an release with preliminary notes
2. Upload assets to the release
3. Iterate through the assets API endpoint to find a specific asset
4. Access the JSON payload to get the correct download path

Alternatively you may just assume something like releases/<tag>/download/<asset name> will be supported regardless of changes implemented by GitHub in the future. Even then HTTP header response-content-disposition: attachment is set meaning browsers try to download the file regardless of the content. This is officially documented here (To link directly to a download of your latest release asset that was manually uploaded, the suffix is '/releases/latest/download/asset-name.zip'.).

There is no supported way to link assets to be viewed within the browser.