gitlab_runner: 81 configuration variables

It's currently way simpler to copy/paste a dozen of shell cmds than going after configuration variables for this role. Seriously seems something is wrong about its "configuration".

1. The big-static-config-pitfall.j2 : Hardcoding the whole file as a j2 template makes this role incompatible with any external and modular modification. A better alternative is:
   1. See that toml is supported by augeas (could have been an Ansible ini_file-like plugin btw)
   2. See that there is an Ansible Augeas module
   3. Then Provide helpers as building-blocks for modular configuration. For example:

  # runner_cache.yml
  toml_file: item="{{ item.n }}" value="{{ item.v }}" section="{{ item.s }}"
  with_items:
    - { n: cache_type, v: "{{ gitlab_runner__cache_type }}", s: runners.cache }
    - ... cache_server_address, cache_access_key, ...

2. Split variables across defaults/main/*.yml directory, organized by topic.
3. Finally drop variables related to edge-cases (at least strip them from the main documentation). Advanced users will find them or implement them (something which becomes possible once we move away from the big-static-config-pitfall.j2)
4. From the 61 variables used in the runner configuration template, 55 are used exclusively for it and most of them could be given sane default offering a clear separation between optional and mandatory configuration
5. Then we are left with:
   • gitlab_runner__additional_groups
   • gitlab_runner__api_fqdn
   • gitlab_runner__api_token
   • gitlab_runner__apt_key
   • gitlab_runner__apt_repo
   • gitlab_runner__apt_upstream
   • gitlab_runner__base_packages
   • gitlab_runner__combined_tags
   • gitlab_runner__comment
   • gitlab_runner__custom_files
   • gitlab_runner__default_tags
   • gitlab_runner__domain
   • gitlab_runner__fqdn
   • gitlab_runner__group
   • gitlab_runner__group_custom_files
   • gitlab_runner__group_tags
   • gitlab_runner__home
   • gitlab_runner__host_custom_files
   • gitlab_runner__host_tags
   • gitlab_runner__packages
   • gitlab_runner__run_untagged
   • gitlab_runner__shell
   • gitlab_runner__shell_tags
   • gitlab_runner__ssh_generate
   • gitlab_runner__ssh_generate_bits
   • gitlab_runner__ssh_install_to
   • gitlab_runner__ssh_known_hosts
   • gitlab_runner__system
   • gitlab_runner__tags
   • gitlab_runner__token
   • gitlab_runner__user
   • gitlab_runner__vagrant_libvirt
   • gitlab_runner__vagrant_libvirt_patch
   • gitlab_runner__vagrant_lxc
     Many of those are simply not worth a variable or can be done by the user and/or are not specific to gitlab-runner. Vagrant, ssh and API are among these.
     Registration is also something out of scope now. Ansible 2.8+ gitlab_runner is used for this.
     Just to take randomly another typical example : gitlab_runner__apt_key: who will reasonably fetch the gitlab authentication key off another HKP server? Even assuming GitLab uploaded it there or is mirrored there (eg: in case of HKP downtime?), then a user is simply going to fetch the key manually or write a 4 lines apt_key task in its own playbook (before even realizing a variable exists for this :))

The only "obstacle" is getting the Toml configuration helper, but then all the rest could be straightforward an lead to an even more modular (but < 10 variables) setup.

NB: I really hoped to be constructive without disregarding at all the [huge & opensource] work that already went into this role.

Start by reading big-static-config-pitfall.j2, the runner configuration template, and the defaults/main/*.yml files to map how the 61 variables are used. Review the Ansible Augeas module and TOML support mentioned in the issue. Done would mean a modular configuration approach, topic-based defaults, and a substantially reduced set of documented variables.