Currently only Metricsets with a predefined query and data structure are possible. Some systems like MySQL allow dynamic queries for additional statistics or metrics to be queried (see Mysqlbeat as an example). JMX is an other example where dynamic queries for metrics are becoming critical. This PR proposes an generic implementation on how to handle dynamic metricsets based on the MySQL example.

A dynamic Metricset is based on an existing metricset. In the example here it is query. The configuration of the dynamic metricset will look as following:

```
- module: mysql
  metricsets: ["query"]
  namespace: "test"
  query: "SHOW STATUS"
  hosts: ["root:test@tcp(127.0.0.1:3306)/beat"]
```

A `query` must be defined for which the data should be fetched and a `namespace` to define under which namespace the data should be put. The namespace is required so the data does not conflict with an other metricset. The resulting event will look as following:

```
{
  "@timestamp": "2016-12-12T08:35:34.711Z",
  "beat": {
    "hostname": "ruflin",
    "name": "ruflin",
    "version": "6.0.0-alpha1"
  },
  "metricset": {
    "dynamic": "query",
    "host": "127.0.0.1:3306",
    "module": "mysql",
    "name": "test",
    "rtt": 16780
  },
  "mysql": {
    "test": {
      QUERY RESULT DATA
    }
  }
}
```

The data is put under the namespace `mysql.test` as the namespace defined was test. Ad additional fields `metricset.dynamic` is added with the original metricset name for easier debugging in case of errors, assuming there could be more then one metricset per module.

MySQL has different result types (SELECT *, COUNT(), SHOW DATABASES, ...). In Mysqlbeat this seems to be detected based on the result structure and based on this some magic happens. An alternative would be to have different dynamic metricsets in mysql and people would have to select the correct one. This would reduce the complexity on the code side but needs more user configuration. At first I would only support one type of queries and extend from there.

The field types of the events are dynamically generated at the moment. For future implementations we could allow a `fields` param in the config which can contain a yaml file with the fields definition out of which dynamically the template is generated and loaded. Alternative a `template` param could be used to point to a template in json format.

TODO:
* Currently errors do not take the event object into account. For the dynamic metricset this is required to make sure the name of the metricset is set correctly.
* Docs
* Code cleanup