Add context to errors in JSON.mapping

[straight-shoota]

Errors from JSON parse methods generated by JSON.mapping are difficult to debug. The message only tells about the immediate error encountered by JSON::PullParser, for example Expected int but was string. At least the source location is attached, but that makes it still quite hard to figure out, what exactly the parser was doing and parsing which object failed, especially in large JSON structures (such as the index.json produced by the docs generator).

This PR adds some context to errors raised by .parse_json by adding the name of the class and property (if available) that is being parsed.
These errors are wrapped, so each level of JSON data is unwrapped and can be followed. It's roughly comparable to a stack trace.

Expected begin_object but was string at 12:10
  parsing Foo at 12:10
  parsing Bar#foo at 12:5
  parsing Baz#bar at 3:15

This exception hierarchy can probably get pretty large with highly nested JSON structures. I'm not sure if the outer contexts are really that useful.

This deep wrapping could be removed and only the significant innermost scope would get wrapped, adding the most important context information.

Obviously, this entire context feature adds some additional overhead to the JSON mapping parser. Exceptions are usually pretty rare, so it shouldn't matter much. In the case it happens, the additional debug info should be worth it.

[asterite]

I like this, but the "exceptions are pretty rare" argument doesn't convince me. Imagine an http server. I can bombard you with invalid json and then you'll waste resources both raising and building that exception message. But since raising is already slow, I don't think there's a fix for this (this is why Go returns an error instead of raising, it's always cheap).

[RX14]

Can you format this with a heredoc to make this readable?