GenericValue: add non-template overload for operator!=

As reported in #113, recent versions of Clang complain about
ambiguous overloads for some comparison operator instantiations,
especially if the deduced template type is a GenericValue.

Add an explicit, non-templated version for now (which is a better
match).

This only solves part of the problem, as comparisons between
  * GenericValue & GenericDocument
  * GenericValue with different SourceAllocator types
will still cause ambiguities.
valuetest: extended value comparison tests

Prepare equalto_operator tests to test comparisons between
 * GenericValue and GenericDocument
 * GenericValue with different SourceAllocator types

Both combinations currently fail due to ambiguities with the
templated operators on several compilers.
improve EN/DISABLEIF macros to support complex templated parameters
meta.h: simplify meta programming helpers

Some (older) compilers have problems with compile-time constants.
This commit simplifies the implementation of the helper classes
in order to improve compiler support, especially be removing the
need of partial template specialisation.

No functional changes.
meta.h: add IsBaseOf meta function

In order to match GenericValue and its derived classes for the
SFINAE-implementation of some of the operators/functions, this
meta-function matches all types equal to or derived from a given
class.  See std::is_base_of<B,D> available in C++11.

Define RAPIDJSON_HAS_CXX_TYPETRAITS to use the C++11 implementation.
GenericValue: use IsBaseOf to support comparisons between Value/Document

This finally fixes #113.
GenericValue: add static assert to catch broken SFINAE

Before applying the simplifications in ed282b814, the SFINAE check for the
GenericValue(bool) constructor has been broken in MSVC 2005. Add a static
assert as a safe-guard against future reappearance of this problem.
Merge pull request #125 from pah/fixes/113

Fix comparison operator ambiguities between Value/Document
valuetest: add test for Uint64 comparisons
GenericValue: fix comparison of (Ui|I)nt64 numbers


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.
Merge pull request #129 from pah/bug/compare-uint64-double

Failing comparisons between certain (Ui|I)nt64 numbers