Feature request: TJsonObject.GetPath should support escaping `.` and `[` in key names

[bflorac]

Summary

TJsonObject.GetPath treats . and [ as unconditional path separators. There is no escape mechanism, so any key name that legitimately contains either character becomes unreachable via the path API — even though JSON itself imposes no restriction on those characters in keys.

Examples that can't be addressed today

{ "my.key": 42 }

GetPath('my.key') navigates into a (non-existent) "my" object and then "key", not into the actual "my.key" property.

{ "items[count]": 7 }

GetPath('items[count]') is parsed as array indexing on "items", not as the literal key "items[count]".

{ "a.b.c": { "x": 1 } }

GetPath('a.b.c.x') cannot reach "x" — there is no way to indicate that the first three segments are one key.

Any document produced by upstream systems that include dots or brackets in identifiers (e.g. config keys, fully-qualified names) loses path access entirely.

Suggested approach

Treat \., \[, and \\ as escape sequences inside name segments — a literal character produced from a backslash plus the next character. Build the unescaped name into a side buffer; use that buffer (rather than the raw [F..EndF) range) for:

• IndexOfPChar lookup
• FNameResolver / FName storage on the leaf
• the auto-create branch (InternAddObject / InternAddArray)

So GetPath('my\.key') resolves to the key "my.key". The fast-forward loop in GetPath needs a small change: when it sees \, skip the next character instead of breaking, and remember to use the unescaped buffer instead of F..EndF.

If helpful, I have a local implementation along these lines and am happy to send a PR.

Related

Adjacent (but distinct) limitation: nested array indexing — filed separately at #89.