Allow custom number types to be used

[eric-wieser]

The std::is_signed<T>, std::is_integral<T> type traits do not permit custom types, and extending these is specified as undefined behavior. Using std::numeric_limits<T>::is_signed and std::numeric_limits<T>::is_integral means that supporting custom types is doable.

This includes a test constructing a very simple integer wrapper type.

In a few places, we have to be a little more precise about what the casts mean.

---

Pull request checklist

Read the Contribution Guidelines for detailed information.

• [x] Changes are described in the pull request, or an existing issue is referenced.
• [ ] The test suite compiles and runs without error.
• [x] Code coverage is 100%. Test cases can be added by editing the test suite.
• [x] 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.

[coveralls]

Coverage remained the same at 100.0% when pulling 876de479530cd111ffd08b2957a172d562c3837d on eric-wieser:custom-integer-types into d4daaa897f48bf7bb2f96b46b84e49f32dd11daf on nlohmann:develop.

[falbrechtskirchinger]

My 2 cents:

• All number types should be allowed to be classes (i.e., number_float_t) - or none at all.
• We need a generic mechanism for serialization/deserialization of numbers. E.g., nlohmann::from_chars and nlohmann::to_chars which are allowed to be specialized for custom types by the user. (This almost became necessary with the json_pointer refactor, if not for constraints placed on number and string types.)
• With generic serialization, we'd enable a range of non-compliant behavior, which has generally been discouraged. Likewise, it could solve many non-compliant feature requests (e.g., NaN serialization but not deserialization, preserving precision across roundtrips).

But first and foremost, get #3575 successfully through CI. I vaguely recall an issue with old MSVCs and unions …