Highlighting can return excerpt with no highlights

You can configure the highlighting api to return an excerpt of a field
even if there wasn't a match on the field.

The FVH makes excerpts from the beginning of the string to the first
boundary character after the requested length or the boundary_max_scan,
whichever comes first.  The Plain highlighter makes excerpts from the
beginning of the string to the end of the last token before the requested
length.

Closes #1171
Minor changes to no_match_size highlight parameter and highlight tests (#1171)

- Randomly store the field to highlight
- Updated test to use common assertions
- Restored previously commented out testCommonTermsQuery
[DOCS] rephrased docs for highlight no_match_size parameter

(removed 0.90.6 coming tag as it's needed only in 0.90 branch)
Upgrade to Lucene 4.5.1
remove trove import from mvel script

all subclasses of trove maps have been removed in 088e05b368
Use at least one query to prevent division by zero in PercolatorFacetsTests
Added third highlighter type based on lucene postings highlighter

Requires field index_options set to "offsets" in order to store positions and offsets in the postings list.
Considerably faster than the plain highlighter since it doesn't require to reanalyze the text to be highlighted: the larger the documents the better the performance gain should be.
Requires less disk space than term_vectors, needed for the fast_vector_highlighter.
Breaks the text into sentences and highlights them. Uses a BreakIterator to find sentences in the text. Plays really well with natural text, not quite the same if the text contains html markup for instance.
Treats the document as the whole corpus, and scores individual sentences as if they were documents in this corpus, using the BM25 algorithm.

Uses forked version of lucene postings highlighter to support:
- per value discrete highlighting for fields that have multiple values, needed when number_of_fragments=0 since we want to return a snippet per value
- manually passing in query terms to avoid calling extract terms multiple times, since we use a different highlighter instance per doc/field, but the query is always the same

The lucene postings highlighter api is  quite different compared to the existing highlighters api, the main difference being that it allows to highlight multiple fields in multiple docs with a single call, ensuring sequential IO.
The way it is introduced in elasticsearch in this first round is a compromise trying not to change the current highlight api, which works per document, per field. The main disadvantage is that we lose the sequential IO, but we can always refactor the highlight api to work with multiple documents.

Supports pre_tag, post_tag, number_of_fragments (0 highlights the whole field), require_field_match, no_match_size, order by score and html encoding.

Closes #3704
Fix nonsensical sentence in standard analyzer documentation so that it is more understandable
Fixed NPE in multi_match query when using lenient and field weight

Closes #3797
Unify REST responses for Acknowledged[Request|Response]

All Rest handlers that use AcknowledgedResponse look identical. Since
we gonna have more of them in the future we can abstract the logic away.
CompletionFieldMapper: Return error if weight is no integer

In order to make sure that people do not get confused, if they
index a float as weight, it makes more sense to reject it instead of
silently parsing it to an integer and using it.

The CompletionFieldMapper now checks for the type of the number which
is being read and throws and exception if the number is something else
than int or long.

Closes #3977
Re-apply pull-request #3956 now that the CLA has been signed.
Don't use TransportClient on FullClusterRestartTests

There seems to be an issue with this test since it shuts down random
nodes and TransportClients seem to be confused due to that. For
now we disable them to figure out if this is the cause of the sporadic
timeouts.
Added Booleans.isBoolean to allow detecting whether a char sequence contains a boolean value. Added XContentParser.isBooleanValue to allow testing if current value is of boolean nature.

Boolean values:
boolean type values
numeric (0 == false)
one of the following strings: "true","false","on","off","yes","no","0","1"
Use XContentParser.isBooleanValue to detect all boolean values for the `_source` parameter for both _mget and _search

 Closes #3981
Added a ClusterHealthResponse.toString implementation for better error reporting in FullRollingRestartTests timeout failures.
Assert on failures in QueryRescorerTests
Make ContextIndexSearcher delegate more method calls to Engine.searcher().

When running tests, Engine.searcher() is going to be an AssertingIndexSearcher
so we definitely don't want to discard it. This commit fixes it as well as the
bugs it found.

Closes #3987
rename and document "index.mapping.date.parse_upper_inclusive" setting for date fields

The setting causes the upper bound for a range query/filter to be rounded up,
therefore the name `round_ceil` seems to make more sense.

Also this commit removes the redundant fourth parameter to DateMathParser.parse(..)
which was never used.
was:    parse(String text, long now, boolean roundUp, boolean upperInclusive)
is now: parse(String text, long now, boolean roundCeil)

closes #3914
Add version to prebuilt analyzers

This patch takes the version of the created index into account when a
prebuilt analyzer is created.
So, if an index was created with 0.90.4, then the prebuilt analyzers
will be the same than on the 0.90.4 release.

One reason for this feature is the possibility to change pre built
analyzers like the standard one.

The patch tries to reuse analyzers as mutch as possible. So even if
version X.Y.Z and X.Y.A use the same lucene analyzers, the same instance
is reused in order to prevent overcreation of lucene analyzer instances.

Closes #3790