Add fleeting subcommand to manage fleeting plugins

What does this MR do?

Adds a fleeting sub-command to gitlab-runner.

fleeting itself has the following sub-commands:

• install to install plugins based on the version constraint found within autoscaler.plugin.
  • upgrade argument will upgrade and install later versions matching the provided version constraint.
• list to list already installed plugins and their path.
• login to store credentials for a registry.

Why was this MR needed?

We needed a way to easily install fleeting plugins.

What's the best way to test this MR?

• Create runner-test.toml:

  [[runners]]
    name = "runner-test"
    token = "abcdefghijk"
    executor = "instance"
    [runners.autoscaler]
      plugin = "aws:0.0.0-bleeding" # registry.gitlab.com/gitlab-org/fleeting/plugins/aws:0.0.0-bleeding or gitlab-org/fleeting/plugins/aws will also work.
      [runners.autoscaler.plugin_config]
        name = "linux-test"

• Run gitlab-runner fleeting -c runner-test.toml list and see that the list is empty (no plugin found).

• Run gitlab-runner fleeting -c runner-test.toml install to install the plugin and have the path reported.

• Run gitlab-runner fleeting -c runner-test.toml list and confirm a plugin now exists and will be used.

• Run ./gitlab-runner --debug run -c runner-test.toml and confirm that the plugin is being used (plugin: starting plugin: path=)

What are the relevant issue numbers?

• Proposal: plugin distribution as a built-in fea... (gitlab-org/fleeting/fleeting#15 - closed)