Add std::string overload to PrettyWriter::Key() when RAPIDJSON_HAS_STDSTRING is #defined

Only String() has the std::string overload currently.

Handle malloc() fail in PoolAllocator

Fix #682

optimize FindMember  when use std::string

Add Flush() for all value types

Fixes #684

also use internal::StrLen to get the string lengtht,
when it call FindMember(StringRef(name)).
Now use GenericValue construct it, then can use the std::string.size.
now it will be faster.

fix rapidjson::value::Get<std::string>() may returns wrong data

Change-Id: Ia7325edb437e3039e29223d0ecc4d9c83d824bc0

Make GenericSchemaDocument constructor explicit

Prior to this change, a user could incorrectly pass a Document object to
SchemaValidator. This would implicitly construct a SchemaDocument, which
would then be destructed before the validator was used. This caused
unpredictable results including memory corruption and program crashes.

Fix buffer overrun using PutN (closes #672)

Fix inconsistent calling of template functions in PutN in stream.h. When
used with a GenericStringBuffer<<UTF8>, MemoryPoolAllocator>, PutN would call
PutReserve from stream.h, and PutUnsafe from stringbuffer.h. This
resulted in bytes being added to the buffer without allocating space.

This was not an issue when used with the default memory allocator,
because in this case the specialized PutN is used from stringbuffer.h.

readertest: Suppress "dangling-else" warning on GCC 7 and later

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

Fix warnings on GCC 6 and later (closes #666)

document typo fix and .gitignore update

* 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

Doxyfile.zh-cn is a generated file that we need to ignore.

Fix undefined behaviour

UBSAN gave in Value.IsLosslessFloat:
include/rapidjson/document.h:981:38: runtime error: value 3.40282e+38 is outside the range of representable values of type 'float'

note that std::numeric_limits<uint64_t>::max() and
std::numeric_limits<int64_t>::max() aren't exactly representable in a
double, so we need to be strictly less to be definitely lossless

UBSAN gave during Value.IsLosslessDouble test:
include/rapidjson/document.h:955:42: runtime error: value 1.84467e+19 is outside the range of representable values of type 'unsigned long'

UBSAN gave in Regex.Unicode test:
include/rapidjson/encodings.h:157:28: runtime error: shift exponent 32 is too large for 32-bit type 'int'

UBSAN gave during Reader.ParseNumber_FullPrecisionDouble test:
include/rapidjson/internal/strtod.h:149:11: runtime error: shift exponent 46 is too large for 32-bit type 'int'

UBSAN gave:
runtime error: division by zero

maybe these tests should just be deleted?

UBSAN gave:
runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long'
runtime error: signed integer overflow: -9223372036854775808 - 2 cannot be represented in type 'long'

UBSAN gave for test/unittest/itoatest.cpp:87:
runtime error: signed integer overflow: 4611686018427387904 * 2 cannot be represented in type 'long'

UBSAN on Clang/Linux gave:
runtime error: null pointer passed as argument 2, which is declared to never be null
/usr/include/string.h:43:45: note: nonnull attribute specified here

UBSAN gave issues with the typeless Schema:
runtime error: reference binding to null pointer of type 'rapidjson::GenericSchemaDocument<rapidjson::GenericValue<rapidjson::UTF16<wchar_t>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >, rapidjson::CrtAllocator>'
and
runtime error: member access within null pointer of type 'AllocatorType' (aka 'rapidjson::CrtAllocator')

UBSAN gave "runtime error: index 13 out of bounds for type 'const uint32_t [10]'"

specifically, "expression with side effects has no effect in an unevaluated context"