Support JSON Pointer (RFC 6901)

Problem solved by the enhancement

Support seeking to a path specified by a JSON Pointer (RFC 6901)

Enhancement description

Add two methods for parsing a JSON Pointer, one for the JSON variant, one for the URI variant. For example:

parse_json_pointer (Note: Adding a _json suffix would probably sound confusing: parse_json_pointer_json)
parse_json_pointer_uri Not sure if the URI variant is common enough to support it though.

The result should be a current Struson JsonPath (i.e. [JsonPathPiece]). Maybe also consider renaming that to JsonPointer?

There would be the following deviations from the JSON Pointer specification (have to be documented):

Parsed JsonPath can be used anywhere in the document, not just the root; respectively applies to the current location
Drop support for - indicating position after last array element; cannot be represented with current JsonPathPiece and would probably not be very useful
Cannot validate that there are no duplicate member names as mandated by JSON Pointer specification
Technically a JSON Pointer as JSON string would require additional quotes around it and escapes; not sure if requiring (or even supporting this) is worth

Possibly also consider supporting Relative JSON Pointer.

Alternatives / workarounds

Instead support parsing JSONPath, however the problems are that:

There is no official specification (?)
It supports complex expressions which would prevent it from being compatible with the current Struson JsonPath implementation used by seek_to

The JSON Pointer specification unfortunately creates ambiguity regarding whether a number (or -) is an object member name or an array index. This cannot be determined from the JSON Pointer and only be decided when evaluating the JSON Pointer against JSON data.

This prevents integrating it with the existing JsonPathPiece since that strictly differentiates between member names and array indices. Also this ambiguity could be error-prone to some extent because it can point to a JSON value even if the JSON data has an unexpected or incorrect structure, maybe that has some security impact.

So for now I think the json_path! macro of Struson is a good and concise enough alternative, and I am not planning to support JSON Pointer.

Marcono1234 / struson