MLT API: fixes many miss behaving user parameters

Previously, the MLT API would create one MLT query per field and per value.
This would make the parameters related to the term selection and query
formation such as `max_query_terms`, `min_term_freq`, `minimum_should_match`
(previously `percent_terms_to_match`) or `boost_terms` behave in an unexpected
manner. Let's take the common example of looking up similar documents with
respect to a list of tag names. Suppose these tags are modeled by a multi-
value field with a keyword analyzer. Performing a MLT request would therefore
result in one MLT query per tag, regardless of the value of `max_query_terms`
or `minimum_should_match`. This would result in a query made of all the tag
names, if `min_term_freq` = 1 (no actual selection of terms is taking place),
or zero tag whatsoever, if `min_term_freq` > 1 (note the default is 2). The
`boost_terms` parameter would also have unexpected effects as it would depend
on the frequency of the term within field value and, again, not within the
whole field.

This commit fixes these issues by calling upon the term vector API and by
directly passing the response (the terms) to the MoreLikeThisQueryParser. Now
both the API and the query yield exactly the same results under any given set
of parameters, but while keeping the added benefit for the API of calling upon
the TV API only once.

Closes #2914
the problem with that is that the response already has a field called `term_vectors` ... But this might not be an issue because it might fit into the new `like` parameter in such a way that any object that has the field "term_vectors" will be treated as a term vector response.

```json
{
  "query": {
    "more_like_this": {
      "like": {
        "_index": "index",
        "_type": "type",
        "_id": "id",
        "term_vectors": {
            "field_name": {
                ...
            }
        }
      }
    }
  }
}
```