Add compatibility section and minor changes about JSON.

User-defined double output precision

GenericValue: add copy constructor and CopyFrom

This commit adds some simple tests for the deep-copying
of values, either based on the explicit constructor, or
the CopyFrom function.

It uses the CrtAllocator to test for possible double-free
errors due to insufficient copying.

To allow deep copying from an existing GenericValue, an
explicit "copy constructor" (with required Allocator param)
and an "CopyFrom" assignment function are added.

  Document d; Document::AllocatorType& a = d.GetAllocator();
  Value v1("foo");
  // Value v2(v1); // not allowed

  Value v2(v1,a);                             // make a copy
  RAPIDJSON_ASSERT(v1.IsString());            // v1 untouched
  d.SetArray().PushBack(v1,a).PushBack(v2,a);
  RAPIDJSON_ASSERT(v1.Empty() && v2.Empty());

  v2.CopyFrom(d,a);                           // copy whole document
  RAPIDJSON_ASSERT(d.IsArray() && d.Size());  // d untouched
  v1.SetObject().AddMember( "array", v2, a );
  d.PushBack(v1,a);

Additionally, the Handler implementation in GenericDocument is made
private again, restricting access to GenericReader and GenericValue.

Instead of always just shallowly referencing the potentially allocated
strings when calling the Handler::String function, request a copy in
case the string has been allocated from an Allocator before.

This is necessary to avoid double free()s of the string memory,
especially when using the Handler to create a deep copy of a Value.

The explicit comparison against '0' is done to suppress the warning
C4800 on MSVC, see pah/rapidjson#5.

As proposed in other patches, it is convenient to pass a user-defined
precision for the (programmatic) output of a single double value
to an OutputStream.

This patch adds an additional overload with an explicit precision
argument to the (Pretty)Writer class templates.

Writing a double to an OutputStream current prints at most 6 significant
digits (according to the C standard).

The function SetDoublePrecision(), added to the Writer classes
can be used to fluently set the precision, i.e. the number of
significant digits to use for writing the double:

  Writer<...> writer(...);
  d.Accept(writer.SetDoublePrecision(12));

some minor fixes

GenericDocument::ParseStream: make SourceEncoding optional

GenericDocument: forward allocator to GenericReader

GenericValue: explicit constructors

GenericValue: fixup construction from NumberType

drop trailing commas in enums

FileStream::current_ is now explicitly initialized in the constructor.
Avoids reading the garbage value in case of an empty file.

The MemoryPoolAllocator implementation cannot and should not be
copied (Rule of Three).  Declare copy constructor and copy-assignment
operator as private.

This patch fixes some misspellings of "allocator" in document.h.
Fixes the Doxygen documentation of GenericDocument as well.

The ParseStream() function current requires explicitly passing
the SourceEncoding parameter as explicit template argument
while the other Parse*() functions provide overloads to omit
this parameter and use the document's own encoding by default.

This patch adds the corresponding overload for ParseStream(),
enabling the simple usage again:

  rapidjson::FileStream is(fp);
  rapidjson::Document   d;
  d.ParseStream<0>(is);

Fixes http://code.google.com/p/rapidjson/issues/detail?id=72.

In case of overloaded functions taking either a GenericValue or another
class that can also be constructed from the same primitive types
(e.g. std::string, which can be constructed from const char*), the
overloading becomes ambiguous:

  void foo( const std::string& );
  void foo( const rapidjson::Value & );

Declaring the GenericValue constructors taking primitive types as
'explicit' avoids this problem.  This should not have any negative
side-effects, since a GenericValue can't be copied or implicitly
converted to other types.

Fixes http://code.google.com/p/rapidjson/issues/detail?id=70.

Constructing an empty GenericValue with a specific Type has failed
for any kNumberType (Int, Int64, Double...) due to incomplete definition
of the corresponding default flag value.

This patch adds a new constant kNumberAnyFlag to the flags enumeration
in GenericValue to cover this case.

This fixes http://code.google.com/p/rapidjson/issues/detail?id=57

In C++'98/03, trailing commas in enumerations are not allowed, but have
been introduced in C++11.  This patch drops the trailing commas in order
to avoid compiler warnings (e.g. GCC with -pedantic).

Fixes http://code.google.com/p/rapidjson/issues/detail?id=49.

This reverts commit e4ffa48a.