Not properly handling release tags containing directory separator (/)

[oddstr13]

Example repository: https://github.com/jellyfin/jellyfin-docs/releases

Log

2020-10-28T22:59:57.670107: Retrieving jellyfin/jellyfin-docs releases
2020-10-28T22:59:57.670280: Requesting https://api.github.com/repos/jellyfin/jellyfin-docs/releases?per_page=100&page=1
2020-10-28T22:59:58.499290: Requesting https://api.github.com/repos/jellyfin/jellyfin-docs/releases?per_page=100&page=2
2020-10-28T22:59:59.272206: Requesting https://api.github.com/repos/jellyfin/jellyfin-docs/releases?per_page=100&page=3
2020-10-28T23:00:00.436950: Requesting https://api.github.com/repos/jellyfin/jellyfin-docs/releases?per_page=100&page=4
2020-10-28T23:00:02.109340: Requesting https://api.github.com/repos/jellyfin/jellyfin-docs/releases?per_page=100&page=5
2020-10-28T23:00:03.173632: Requesting https://api.github.com/repos/jellyfin/jellyfin-docs/releases?per_page=100&page=6
2020-10-28T23:00:03.682053: Saving 510 releases to disk
Traceback (most recent call last):
  File "/home/oddstr13/.local/bin/github-backup", line 42, in <module>
    main()
  File "/home/oddstr13/.local/bin/github-backup", line 37, in main
    backup_repositories(args, output_directory, repositories)
  File "/home/oddstr13/.local/lib/python3.8/site-packages/github_backup/github_backup.py", line 820, in backup_repositories
    backup_releases(args, repo_cwd, repository, repos_template,
  File "/home/oddstr13/.local/lib/python3.8/site-packages/github_backup/github_backup.py", line 1029, in backup_releases
    with codecs.open(output_filepath, 'w+', encoding='utf-8') as f:
  File "/usr/lib/python3.8/codecs.py", line 905, in open
    file = builtins.open(filename, mode, buffering)
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/games/github_archives/jellyfin/repositories/jellyfin-docs/releases/ci/6384.json'

There are two ways one could go about fixing this;

1. Replace '\' and '/' with '-' (or another appropriate character)
2. Create the directory (ci/ in this case)

Number 1 shouldn't require additional code for tools accessing the resulting data, but number 2 could potentially be easier to browse manually.

[whwright]

This is fixed in #174