Internal: Move plugin manager to new CLI

PluginManager could now be rewritten using the new Command Line Interface framework.

# How does it work?

The new `bin/plugin` tool works now as this:

```
bin/plugin command [options] <command_parameter>
```

`command_parameter` could be mandatory depending on the `command`.

## Generic options

Some options could be applied to any plugin command:

* `--help`, `-h`
* `--silent`, `-s`
* `--verbose`, `-v`

## Install

```
bin/plugin install [options] <plugin_name>
```

`plugin_name` is mandatory. Still using the same form as used before with the plugin manager.

Options could be:

`--timeout <timeout_value>`, `-t <timeout_value>`
`--url <url>`, `-u <url>`

## Uninstall (Remove)

```
bin/plugin uninstall [options] <plugin_name>
```

`plugin_name` is mandatory. Still using the same form as used before with the plugin manager.

## List

```
bin/plugin list [options]
```

# Breaking changes

Some important changes for `bin/plugin` application:

|      Old option       |      New option        |
|-----------------------|--------------------------|
| `--install pluginname`              |`install pluginname`                     |
| `-i pluginname`                       |`install pluginname`                     |
| `-install pluginname`               |`install pluginname`                     |
| `--remove pluginname`              |`uninstall pluginname`                     |
| `-r pluginname`                       |`uninstall pluginname`                     |
| `-remove pluginname`               |`uninstall pluginname`                     |
| `remove pluginname`               |`uninstall pluginname`                     |
| `-l`                       |`list`                     |
| `--list`               |`list`                     |
| `-url <url>`                       |`--url <url>` or `-u <url>`                     |
| `url <url>`                       |`--url <url>` or `-u <url>`                     |
| `-verbose`                       |`--verbose` or `-v`                     |
| `verbose`                       |`--verbose` or `-v`                     |
| `-silent`                       |`--silent` or `-s`                     |
| `silent`                       |`--silent` or `-s`                     |
| `-timeout <time>`                       |`--timeout <time>` or `-t <time>`                     |
| `timeout <time>`                       |`--timeout <time>` or `-t <time>`                     |

But the new PluginTool still support for elasticsearch 1.4 old options/commands format and will translate old options to the new one.

Deprecated format will be removed in an upcoming version (1.5? or 2.0?)

# Tests

Many tests have been adapted to the new CLI. Some randomization has been added as well.
New tests have been added as well.

Also, I ran some manual end user tests such as:

```sh
# Test non existing plugin
bin/plugin install dummy/donotexist
bin/plugin install dummy/donotexist -v
bin/plugin install dummy/donotexist -s
# Test es.org download service
bin/plugin install elasticsearch/elasticsearch-cloud-azure/2.4.0
bin/plugin uninstall elasticsearch/elasticsearch-cloud-azure/2.4.0
# Test maven central download
bin/plugin install org.elasticsearch/elasticsearch-cloud-azure/2.4.0 -v
# Test install from github master download
bin/plugin install mobz/elasticsearch-head -v
bin/plugin uninstall mobz/elasticsearch-head
# Test install using URL
bin/plugin install head -v -u https://github.com/mobz/elasticsearch-head/archive/master.zip
# Test list plugins (with empty or one or many plugins)
bin/plugin list
```

# Remaining questions

* We change `PluginManager` class name to `PluginTool` class name. Should we keep the old name (so we don't change `bin/plugin` and `bin/plugin.bat` files)?
* This PR contains a fix when CLI is set to `silent` but in case of error it still prints out an error message. Should this be part of another PR? See https://github.com/dadoonet/elasticsearch/commit/25d332b8d5335f22693d26bc4e57d5d5522b5c7c

Related to #7094

does it make sense to throw an exception here or is it better to return another `ExitStatus`?