Serialize subject and predicate literals correctly

[joachimvh]

Closes #329

This does have as disadvantage that invalid turtle will be generated if quads get added to the writer that can not be represented in turtle. If that is a problem, an alternative solution would be to have variants of the writer, similarly to how n-quads get handled, where the turtle version throws an error if it encounters a literal in the subject/predicate position and the N3 version handles it correctly. Let me know what you prefer and I can update the PR.

[RubenVerborgh]

invalid turtle will be generated if quads get added to the writer that can not be represented in turtle

I wonder if this has repercussions for #339; should we have a generic flag for "out of syntax features"?

[RubenVerborgh]

Perhaps we should still keep _encodeSubject and _encodeObject around, just so we can error in those functions as needed.

[jeswr]

I wonder if this has repercussions for #339; should we have a generic flag for "out of syntax features"?

...perhaps, though I worry about performance degradation doing it internally; we could just supply validTurtleQuad, validN3Quad etc. functions that consumers can optionally pass their data through first to validate.

[jeswr]

As an aside - are there any RDF syntaxes that don't support a shortand in the subject or object position? If not then the following logic could just be moved to _encodeTerm

N3.js/src/N3Writer.js

Line 207 in c7540c4

return predicate.value === rdf.type ? 'a' : this._encodeTerm(predicate);

[joachimvh]

As an aside - are there any RDF syntaxes that don't support a shortand in the subject or object position?

Turtle only allows it in the predicate position.