Support for integer types with non-trivial destructors, copy, and move constructors

[eric-wieser]

Currently it is not possible to set number_integer_t or number_unsigned_t to types with nontrivial destructors, move constructors, copy constructors, or assignment operators.
This means it's not possible to use types that wrap the mpz API from the gnu multiple precision arithmetic library.

To use custom types at all, we move from using std::is_signed<T>, std::is_integral<T> etc (which do not support custom types) to using std::numeric_limits<T>::is_integral etc (which do). This is #3577.

This would be a lot easier if json_value were implemented using std::variant, which does all the tagged-union book-keeping for us. The basics of tagged union book-keeping are:

• Assignment to the raw union are illegal. Once a union is uninitialized with the existing destroy, it can be assigned to with new (uninit_value) json_value(new_type, new_value).
• The destroy function needs to manually call destructors on the parts not being handled with an allocator

This adds a test containing a jankily-written heap_int type to verify that this new feature works.

[Describe your pull request here. Please read the text below the line, and make sure you follow the checklist.]

---

Pull request checklist

Read the Contribution Guidelines for detailed information.

• Changes are described in the pull request, or an existing issue is referenced.
• The test suite compiles and runs without error.
• Code coverage is 100%. Test cases can be added by editing the test suite.
• The source code is amalgamated; that is, after making changes to the sources in the include/nlohmann directory, run make amalgamate to create the single-header file single_include/nlohmann/json.hpp. The whole process is described here.

Please don't

• The C++11 support varies between different compilers and versions. Please note the list of supported compilers. Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with #ifdefs or other means.
• Specifically, I am aware of compilation problems with Microsoft Visual Studio (there even is an issue label for these kind of bugs). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
• Please refrain from proposing changes that would break JSON conformance. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
• Please do not open pull requests that address multiple issues.