More tests for alex innovation json

Added tests of the JSON function SET_FIELD, plus a few more for FIELD, including with dotted path and/or array index notation, and with dot and bracket characters not used in that way (and therefore escaped with a backslash), and using numeric, floating point data.
I'd distinguish an empty string doc or path here from a SQL null doc or path, and restore the conventional null-in -> null-out semantics when either of those arguments is null, for consistency with the FIELD function and most other SQL functions.
The handling of SQL null for the value argument is a little more questionable.
We COULD keep this implementation as-is, making it a special-case exception to the "null in --> null out" rule.
For absolute correctness, this would have implications for some obscure edge cases involving using SET_FIELD in a filter in an OUTER JOIN, but we could probably just ignore that as a "known documented anomaly".

Actually, I'm not sure what the current implementation is really doing with the null value. There should be test cases for this.

OTHERWISE, strictly applying "null in --> null out" here could be very surprising especially in the common use case:
"UPDATE TABLE SET JSON = SET_FIELD(JSON, "attribute.minor", ?) WHERE KEY = ?"
If the user passes a null for the first query parameter, they would null out the entire JSON field, probably not the intent.

OTHERWISE, another alternative would be to throw a runtime error on a null value argument.