Add nullptr Json::Value constructor

[nathanruiz]

I found some unexpected behavior when using this library when comparing a Json::Value to nullptr. This was my sample program:

#include <jsoncpp/json/json.h>
#include <iostream>

int main()
{
    Json::Value test("Hello world!");
    Json::Value test2(Json::nullValue);

    if (test == nullptr)
    {
        std::cout << "test is null" << std::endl;
    }

    if (test2 == nullptr)
    {
        std::cout << "test2 is null" << std::endl;
    }

    return 0;
}

Since before this change, Json::Value objects can be compared with other Json::Value objects, a implicit Json::Value object will be constructed with nullptr as it's parameters. Given the only valid constructor for nullptr was the const char *, the program aborts with the following output:

terminate called after throwing an instance of 'Json::LogicError'
  what():  Null Value Passed to Value Constructor
Aborted

To improve this experience, I've explicitly deleted the nullptr_t constructor, so that the above code will result in a compile time error.

[coveralls]

Coverage remained the same at 93.801% when pulling d768367 on nathanruiz:master into 632044a on open-source-parsers:master.

[BillyDonahue]

I really don't think adding a new type-equivalence to Json::Value is the right direction to go. I sympathize with the accidental const char*, but trying to compare a Json::Value to a nullptr is a coding error. If it's accepted as a valid Value holding a nullValue, then the error would be undiagnosed.

This change introduces a new equivalence of nullptr_t to the Json::nullValue.
I don't think they're equivalent concepts. I would prefer adding a deleted constructor
to make the aforementioned ambiguity a build failure:

Value(std::nullptr_t) = delete;

[nathanruiz]

That is probably a better outcome. I've changed the code to do what you've suggested.