add `Key()` method to the `Handler` concept

It was a copy-n-paste error for the last argument of `Key()` and `String()`...

For more details see: https://github.com/miloyip/rapidjson/issues/132

This commit tries to minimize the required code changes and forwards the `Handler::Key()` calls to `Handler::String()` wherever possible in order to not break existing code; or at least not code deriving from `BaseReaderHandler` when implementing a custom `Handler`.

Initial C++11 move support

GenericValue: accept values with different allocators for read-only access

This shall generate best possible precision (if strtod() is correctly
implemented). Need more unit tests and performance tests. May add an
option for accepting precision error. Otherwise LUT in Pow10() can be
reduced.

GenericValue: reduce growth factor for array/object reallocations

short string optimization

The `ShortString` can represent zero-terminated strings up to `MaxSize` chars (excluding the terminating zero) and store a value to determine the length of the contained string in the last character `str[LenPos]` by storing `MaxSize - length` there. If the string to store has the maximal length of `MaxSize` (excluding the terminating zero) then `str[LenPos]` will store `0` and therefore act as the string terminator as well. For getting the string length back from that value just use `MaxSize - str[LenPos]`.

This allows to store `11`-chars strings in 32-bit mode and `15`-chars strings in 64-bit mode inline (for `UTF8`-encoded strings).

Suggested-by: @miloyip

Instead of replicating the functionality of `GetString()` and `GetStringLength()` in `StringEqual()` it now calls these methods instead.

Since the payload (the `Data` union) of the current implementation of `GenericValue` is `12 bytes` (32 bit) or `16 bytes` (64 bit) it could store `UTF8`-encoded strings up to `10` or `14` chars plus the `terminating zero` character plus the string length:
``` C++
    struct ShortString {
        enum { MaxSize = sizeof(GenericValue::String) / sizeof(Ch) - sizeof(unsigned char) };
        Ch str[MaxSize];
        unsigned char length;
    };  // at most as many bytes as "String" above => 12 bytes in 32-bit mode, 16 bytes in 64-bit mode

```

This is achieved by introducing additional `kInlineStrFlag` and `kShortStringFlag` flags. When setting a new string value in `SetStringRaw(s, alloc)` it is first checked if the string is short enough to fit into the `inline string buffer` and if so the given source string will be copied into the new `ShortString` target instead of allocating additional memory for it.

As mentioned by @kosta-github in http://git.io/0gkYSg, the currently
used growth factor of 2 is suboptimal for memory performance.  An
extensive discussion can be found at [1].

This patch reduces the array/object capacity growth factor to 1.5, as
many C++ implementations have chosen to use.  In order to avoid
floating-point arithmetics for computing the new capacity, I did not
add any customization parameter for the factor and used a shift+add
instead.

[1] https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md

Failing comparisons between certain (Ui|I)nt64 numbers

 * constructor from array is RAPIDJSON_NOEXCEPT
 * constructor from plain pointer missed an assert

 * Move()
 * RawAssign()
 * SetStringRaw()

Some 64-bit integers cannot be represented losslessly as a double.
Due to a typo in the operator==, the comparison has been performed
after a double conversion in too many cases.

Added basic detection of `noexcept` support for some compilers, added
corresponding RAPIDJSON_NOEXCEPT annotations to
 * non-allocating constructors
 * (move) assignment
 * Swap

Directly allows temporary GenericValues as parameters:
  v.AddMember("foo", Value(s.c_str(),alloc), alloc);