Return a JSONError value with an error string if parsing fails

[benswick]

Currently, parse failures return NULL and I just have to print a generic "something went wrong" message. It would be nice to have some kind of error message pointing to the line with the problem.

This change makes the parse functions try to return a value of type JSONError with a string value containing an error message. If it cannot allocate the value then it still returns NULL. I updated the test code accordingly. Since this could break programs that expect only NULL on failure I hid it behind a preprocessor definition.

The only other API change is adding const char* json_value_get_error(const JSON_Value *value).

The main limitation is that the error message contains the line number after comments are removed which may not match the line number the user sees in a file. The error message also contains part of the line that parsing failed on, so users could notice the line number and line content do not match.

I've considered a few other related changes but did not want to make overly invasive changes without finding out your preferences.

• Removing the preprocessor definition and always returning JSONError values.
• Adding a run-time setting instead of a preprocessor definition.
• Detecting whether any removed comments included a newline and suppressing the line number.
• Creating a json_parse() function that accepts a struct with the filename/string and feature flags (remove comments, return error values, skip line numbers, etc).
• Generating more informative messages without invasive changes to the parsing code by looking at the text around where the parse failed. Examples:
  • If the parse failed on ] explain that it is an unmatched array bracket.
  • If the parse failed on }, and the previous non-whitespace character is a comma then explain that trailing commas are invalid.

It's no problem if you want to rewrite any of this or would prefer me to implement it differently. I tried to match the existing code and comment style.

[kgabis]

As explained in #79 (comment)