Fix accidental ABNF omission for Relative JSON Pointer

[handrews]

Fixes #1175 (doing another RJP draft was discussed and agreed to several months ago).

Taking the index of the result of an index manipulation was shown in the example and intended to work, but left out of the ABNF apparently by accident.

Also, rework the ABNF to keep it within the text RFC line width.

[awwright]

This is good, also note *( %x30-39 ) is the same as *DIGIT if you want to incorporate that here too.

[handrews]

@awwright I take it that 0 is written in the ABNF as %x30 because we're describing a string rather than numbers? *DIGIT is more readable but since we have to have the hex for the others maybe it makes more sense to leave it? Hmm...

[awwright]

%x30 is identical to "0"... though it wouldn't be if it were a letter (double quote = case insensitive, %x = case sensitive).
%x31-39 is probably preferred because it's the terse version of "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"

[awwright]

I would propose this:

            <t>
                The ABNF syntax of a Relative JSON Pointer is:
            </t>
            <sourcecode type="abnf9110"><![CDATA[
  relative-json-pointer = origin-specification json-pointer
                        / origin-specification "#"
                        ; json-pointer from RFC 6901

  origin-specification  = non-negative-integer [ index-manipulation ]
  index-manipulation    = ( "+" / "-" ) non-negative-integer
  non-negative-integer  = "0" / %x31-39 *DIGIT
                        ; zero, or digits without a leading zero
]]></sourcecode>

In addition to the things I talked about above, this replaces the figure element with sourcecode; I changed to the / operator from =/ which is usually reserved for extending a production in another specification; and I changed json-pointer to a literal rule name, from a prose-val which is usually reserved for describing non-regular rules.

[handrews]

@awwright I've incorporated your suggestion, does this look correct?

[handrews]

The force-push / added 4 commits was just me re-basing to pick up the 2022->2023 build fix.

[gregsdennis]

Closing in favor of 👇 which has some additional commits. (☝️ was created in a fork)