Escape n3 triples to deal with multiline issues

[joshmoore]

@andrawaag has been running into issues with various parsers due to the newlines in literals:

http://www.openmicroscopy.org/rdf/2016-06/ome_core/Value      """<SegmentDefinition>
          <Name>example</Name>
          ...
        </SegmentDefinition>""" .

Based on:

• https://stackoverflow.com/questions/15392730/in-python-is-it-possible-to-escape-newline-characters-when-printing-a-string
• https://stackoverflow.com/questions/74643162/python-rdflib-string-to-uriref-or-literal-inverse-of-n3-method
  produces strings with embedded \n escapes:

<http://www.openmicroscopy.org/rdf/2016-06/ome_core/Value>      """<ChannelThresholds>\n          <RoiName>012</RoiName>\n 

If this is not sufficient, then we may need to create a Graph object very frequently and use the .serialize() method.

[joshmoore]

Merging for release in the 0.5.x line for testing during https://www.denbi.de/de-nbi-events/1678-biohackathon-germany-3

If it needs reverting, we can do that quickly (and/or put it behind an option)

[joshmoore]

A heads up that this apparently is failing for graphDB on the micro symbol

_:N601882e7d0f24751893771b77ef8b624     http://www.openmicroscopy.org/rdf/2016-06/ome_core/Symbol     "\xb5m"

[andrawaag]

I am not sure if this issue is related. That microsymbol is not part of a multiline triple, but a proper triple where graphDB is complaining about the escape sequencing.
The quick (and dirty) fix where "\xb5m" is changed into "xb5m"

seem to have "solved" it

[joshmoore]

That's fine. I think it more points to what's being used for escaping. I out then together in #28 since I think we'll need graphDB in the testing mix.

Cc @CFGrote