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"

clang advises: "note: silence by adding parentheses to mark code as explicitly dead"

switch Clang from broken Ubuntu PPA to upstream binary release

This should fix the Travis clang builds, since the upstream LLVM apt
repo is down.

npm docs

Fix cmake build with new gtest reference

Allow options for writing and parsing NaN/Infinity

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.

npm compliant package.json

fix some document problem

Added missing include guards in istreamwrapper.h and ostreamwrapper.h

Fix filterkeydom link

Define RAPIDJSON_HAS_CXX11_RVALUE_REFS directly in clang

This makes no difference except that it avoids "warning: macro expansion
producing 'defined' has undefined behavior" messages.