gitlab support

[torkus]

• [x] gitlab addons can be added to the user-catalogue via 'import addon'
• [x] gitlab addons can be checked for updates
• [x] all of WobLight's addons can be installed: https://gitlab.com/woblight
  • most of them can. Those that haven't been updated in a few years with no releases/assets can't.
  • anyone else we should be looking at?
• [x] consult toc file for supported game tracks (like github)
  • ehhhh ... yeah. probably should. even with multi-toc, there may be a case of a classic-only addon not otherwise indicating in it's releases that it supports classic and we default to retail.
• [x] looks for multiple toc files to determine game track support
  • jumping the gun a bit for this months work, but it was easy to implement
• [x] game track can be detected for releases (examples?)
  • 'link' name on release is checked and that is all
• [x] support multiple 'links' in a release
  • not that I've found any examples.
• [x] bug, the list of available releases has a warning about no release that keeps changing addon. very weird!
  • wasn't handling an empty list of game tracks very well
  • that's not the only thing. I think the logging for gitlab addons is a bit broken
    • found it, problem is in the log flooding detection. fml. the trickiest thing to fix in this bucket.
    • disabled it for now but will keep an eye out for any flooding
• [x] alpha/beta/no-lib releases stripped from available releases
  • I'm not doing this for github, which has the notion of a 'pre-release'.
  • Gitlab uses a future date for the released_at field and a upcoming_release boolean
• [ ] ~bug, refresh user catalogue is pretty rough~
  • will be a separate fix
• [x] review
• [x] update README
• [x] update CHANGELOG

[torkus]

good progress:

looks like gitlab addons will be similarly constrained like github addons: they must be using 'releases' with attached 'assets' (and not the default ones). This is fairly new in gitlab-land (last year? two?).