Runner version support strategy

[LongLiveCHIEF]

See #46 (comment)

Gitlab provides an interesting case where it only supports the last 3 releases, (and they release monthly on the 22nd. With the puppet-gitlab module, being fairly stable, usually new releases for our module don't provide new features, they just accommodate new config options in the omnibus config file.

That allows us to tell users to use an older version of the module if they're using an older (non-supported) version of gitlab.

We should probably think about how this plays out with gitlab-runners. Runner releases are loosely versioned along with GitLab, but updating gitlab does not update runners. It is not uncommon for a gitlab installation following zero day releases to have runners at least one major version behind registered with it.

Should this module adopt a support strategy similar to the puppet-gitlab module, or should we strive for a greater period of backwards compatibility as much as possible?

Note: Gitlab will likely be incrementing major versions from v11 to v12 in July.