See issue #1368.

Sometimes, particularly when Microsoft's windows.h is included, min/max
are defined as macros, interfering with use of
std::numeric_limits::min() and the like.

To guard against this, the function name is wrapped in an extra set of
parenthesis, which inhibits function-style macro expansion.

This is a similar commit to 6e38649e, but fixes uses of
std::numeric_limits added after that commit, like those introduced in
2ea43433.

until I know what the normal-precision algorithm really does...

Some more need to be fixed.

When parsing negative exponents, the current implementation takes
precautions for |exp| to not underflow int.

But that is not sufficient: later on [1], |exp + expFrac| is also
stored to an int - so we must ensure that the sum stays within int
representable values.

Update the exp clamping logic to take expFrac into account.

[1] https://github.com/Tencent/rapidjson/blob/master/include/rapidjson/reader.h#L1690

A failed half-consume of “NaN” now returns “value invalid” instead of
attempting to consume an “Inf”.

Noticed that the reader could over-consume “NaN” if token terminated in
the middle.

New unit test which ensures that IterativeParseNext always generates
exactly one element at a time, and that calling IterativeParseNext on a
complete document is harmless and generates zero events.

Fix #824

GCC 6.x doesn't yet support this warning flag, as reported by
@ragnar-ouchterlony.

* document.h
  * suppress -Wterminate on GCC 6.x and later
  * simplify warning handling
* schema.h
  * drop RAPIDJSON_NOEXCEPT from GenericSchemaDocument constructor
    (calls RAPIDJSON_NEW anyway)
  * simplify warning handling
    (avoids RAPIDJSON_POP mismatch on Clang)
* encodingtest.cpp, istreamwrappertest.cpp
  * work around -Wdangling-else
* readertest.cpp
  * suppress -Wdangling-else

This adds kWriteNanAndInfFlag to Writer to allow writing of nan,
inf and -inf doubles as "NaN", "Infinity" and "-Infinity",
respectively, and kParseNanAndInfFlag to Reader to allow parsing
of "NaN", "Inf", "Infinity", "-Inf" and "-Infinity". This is part
of issue #36, adding optional support for relaxed JSON syntax.

Later clang compilers will warn on float -> double promotion because it can add precision. In the context of RapidJSON – especially with its float methods on GenericValue – I think this warning holds no water and should be ignored.

Trim whitespace off the end of various lines.

Added an additional NumberStream specialization that will always perform a TakePush() even when just Take() is called. This supports RawNumber parsing by pushing onto our StackStream particular parts of the number that currently aren't captured because of full precision double parsing, such as the negative sign, scientific number exponents, etc.

RawNumber parsing fails with input streams that don't have copy optimization, such as the BasicIStreamWrapper stream. To work around this, instead do the Transcode copy operation by reading from a UTF8 StringStream instead of the original InputStream. Since the NumberStream downcasts all input Ch into chars, we know we're dealing with UTF8/ASCII compatible stack characters during the Transcoding.

This also fixes cases where the iterative parser should have produced
kParseErrorValueInvalid rather than kParseErrorUnspecifiedSyntaxError
when expecting a value (after a colon in an object, after a comma in an
array, and at the start of an array.)

This adds kParseTrailingCommasFlag to allow a trailing comma at the
end of maps and arrays. This is part of issue #36, adding optional
support for relaxed JSON syntax.