extend language maps to support base direction

currently, language maps in JSON-LD allow to create literals with a language tag, but not with a base direction, which is not good from an i18n point of view.
If you want to to express the title of a book about JSON-LD both in English and Arabic, you need the following (expanded) JSON-LD:

{
    "http://schema.org/title": [
        { "@value": "JSON-LD and Linked Data", "@language": "en", "@direction": "ltr" }
        { "@value": "JSON-LD والبيانات المرتبطة", "@language": "ar", "@direction": "rtl" }
    ]
}

but you can't get this result with a language map.

A workaround is possible by defining different properties with language maps, one for ltr titles, and one for rtl titles (see example in the playground). But that requires contexts designers to provision it.

An alternative would be to extend the expansion algorithm for language maps, to accept a special format in their keys containing both language tag and optionally a base direction. All we need is an encoding which is not ambiguous with valid language tags. A possible separator would be --, which is what Turtle uses. Another possible separator is a space, but it is less YAML-friendly (and actually looks odd, spaces in keys are not usual).

Example:

{
  "@context": {
    "titles": {
      "@id": "http://schema.org/title",
      "@container": "@language",
      "@context": {
        "@direction": "ltr"
      }
    }
  },
  "titles": {
    "en": "JSON-LD and Linked Data",
    "ar--rtl": "JSON-LD والبيانات المرتبطة"
  }
}

Start with the JSON-LD 1.1 language maps section and its expansion algorithm, then compare the current behavior with the examples in this issue. Define an unambiguous encoding for a language tag with an optional base direction, and update the specification so the example produces expanded values containing both @language and @direction while ordinary language-map keys continue to work.