Adding new Deploy and Publish steps to GitLab CI (simplifying releases)

[jonoomph]

This PR was really fun to work on. This adds new automation into the GitLab CI OpenShot release process, with 2 additional manual jobs. They only appear on release* named branches.

Deploy Step:

• Creates all 3 GitHub Release objects (libopenshot-audio, libopenshot, and libopenshot-qt)
  • Each one contains a markdown formatted list of all git log changes
  • Each one is set to 'Pre-Release' mode, and contains a few placeholders for highlights
• Adds all 3 combined git log changes to the openshot-qt GitHub Release object
• Uploads all previously built and tested installers (and renames them) from the release* branch into the new openshot-qt GitHub Release object. This is a big change from before, where we would re-build the installers again.
• Creates sha256sum files for each installer (uploads them to GitHub release as well). This will be integrated into our openshot.org/download page soon.
• Creates new .torrent files, for the renamed installers
• Creates new blog post on openshot.org, with all git log changes, formatted in HTML, with some placeholders for highlights. Status set to 'Draft' and 'Un-published'.
• Creates new Release version on openshot.org (visible set to False), linked with new blog post. This is what updates the version info displayed on openshot.org.
• Does lots of cool validations, which fail the deployment:
  • Validate GitHub releases are not already published for these versions
  • Validate all installer uploads have the same sha256sum, after uploading and re-downloading them
  • Validate all 3 repos have the same branch name (i.e. release*...)
  • Validate all 3 repo versions do not contain a - character (i.e. such as -dev1)
  • Validate branch names start with release*
  • Validate /deploy/ endpoint on openshot.org succeeds (which creates the blog and release version data)

Publish Step:

• Validate /publish/ endpoint on openshot.org succeeds (which makes the blog and release version visible and published)
• Set all 3 GitHub Release objects to Released
• Validations:
  • Validate that the openshot.org/download/ page contains the new version string
  • Validate all downloadable files on openshot.org/download/ (i.e. sha256sum, torrents, installers) are valid URLs and not broken links
• Clear all cache on openshot.org, to display the new version and new download page

[ferdnyc]

@jonoomph
Uh, merging this PR bumped the openshot version to 2.5.2 and raised the minimum libopenshot version to 0.2.6 — which doesn't exist yet. IOW, this "release-testing" branch became a premature release.