The `geohash_cell` filter now adapts the format of other geo-filters. The oject fieldnames match the fieldnames document names automatically. This invalidates the `field` field in previeous versions. The value these fields value is a `geo_point` value (all formats supported) which is internally translated to a geohash. Since those points alway have a maximum precision (level 12) a `precision` definition has been included. This precision can either be defined as *length* of the geohash-string or as *distance*. It's assumed the a distance without any unit is a geohash-length.

```
GET 'http://127.0.0.1:9200/locations/_search?pretty=true' -d '{
    "query": {
        "match_all":{}
    },
    "filter": {
        "geohash_cell": {
			"pin": {
				"lat": 13.4080,
				"lon": 52.5186
			},
            "precision": 3,
            "neighbors": true
        }
    }
}'
```
Closes #3229
Made the minimum score only active when executing the main query and not during the context rewrite phase.

This fixes parent/child queries when using minimum_score.

Closes #3203
A small doc change to reflect StreamOutput.writeVInt() does support negative numbers but not efficiently. StreamOutput.writeVLong & StreamInput.readVLong really support it.

This is to better describe the current situation. We probably want to normalize these methods and potentially add optimization/support for -1 values.
Fix field number attribution to _version.

IndexUpgraderMergePolicy assumed that field numbers were dense and that
fieldInfos.size() was a free field number. This can however be wrong for a
segment which doesn't have one or more fields that some older segments have.

Close #3237