Add a possibility to implement explicit Converter<U, String> to JSON, XML, CSV import / export

[lukaseder]

Currently, all "unknown" data types are serialised by calling toString() simply. Deserialisation of such values is currently not possible. Users should be able to intercept this with Converter<T, String> SPIs that they can provide to individual serialisation / deserialisation calls, or globally.

These could also influence MULTISET emulations.

Tasks

• New FormattingProvider SPI methods that allows for registering global import / export serialiasers / deserialisers in the form of Converter<U, String> for
  • CSV
  • JSON
  • XML
  • TXT
• Refactor various default behaviour to be implemented directly in this SPI's default implementation, instead of the various formatters, parsers, for
  • CSV
  • JSON
  • XML
  • TXT
• Explicit overrides on a per field basis in the Loader API: Add support for Converters in the Loader API #3221
• Study interactions with native support for
  • SQL/JSON
  • SQL/XML

---

See also:

• Add "converter" and "binding" information to JSON and XML exports / imports #5670
• Support HSTORE data type in MULTISET #15283
• https://groups.google.com/forum/#!topic/jooq-user/gMbM-a1CdJA

[lukaseder]

These mappings could also help influence MULTISET emulations. At least it should be investigated how the two feature sets interact. The new converters are all about reading strings from JSON / XML, but we might also want to be able to influence the serialisation on the SQL side, e.g. using custom CAST expressions, etc.

[lukaseder]

This is also useful for the Loader API: #3221