value object with `"@type": "rdf:langString"`

Consider the following:

{
  "x:p": {
    "@value": "foo",
    "@type": "http://www.w3.org/1999/02/22-rdf-syntax-ns#langString"
  }
}

It is currently a valid JSON-LD document, even though it corresponds to an invalid RDF graph (because a literal with datatype rdf:langString but no language tag is not allowed in the abstract data model.
In fact, this causes an ambiguity in the toRdf algorithm, which does not tell you what to do with this pathological case, and implementations diverge.

• jsonld.js simply "eats" the datatype, turning it implicitly into (permalink)
• sophia faithfully produces "foo"^^rdf:langString (permalink), but then refuses to parse the resulting n-quads (permalink)
• PyLD raises an error

Proposed solution: we should refine the definition of value object to forbid @type to have value http://www.w3.org/1999/02/22-rdf-syntax-ns#langString (and, eventually, http://www.w3.org/1999/02/22-rdf-syntax-ns#dirLangString).
Accordingly, the Expand algorithm should raise an "invalid value object" error when it is lead to create such an object (e.g. via IRI expansion and/or type coercion).

Start with the JSON-LD 1.1 value objects definition and the Expand algorithm referenced in the issue, then compare the jsonld.js, Sophia, and PyLD behaviors described. Done means the specification clearly forbids the invalid rdf:langString value object and defines the corresponding invalid value object error, including any decision about rdf:dirLangString.