Facilitate the capacity for creating translations of data hosted in other networks

Let's make "[ontology](https://github.com/holo-rea/ecosystem/wiki/Modules-in-the-HoloREA-framework#ontology)" a bit more accessible.

What we need is "**dictionary**" and "**translation**".

### Dictionary

A zome API interface which enables the storage of key/value string pairs for direct retrieval by key.

- These could be used as *actual* dictionaries within specific community cultural contexts, in order to assist with making concepts and norms accessible to newcomers
- Could also be used as i18n containers for apps; might be nice to implement [POT file](https://www.drupal.org/community/contributor-guide/reference-information/localize-drupal-org/working-with-offline/po-and) interoperability

Bonus points for an ability to compose this with [fulltext indexing](https://github.com/holochain-open-dev/ecosystem/issues/24) in order to make the lookup keys accessible by search.

### Translation

A zome API interface which attempts to describe concepts between different languages.

Could be implemented as a composition of "**dictionary**" that adds DNA properties for the "origin" and "translated" languages, and method(s) for registering the translation zome with a host application.

For example, in a zome where `origin=en-UK` and `translated=fr-FR` we may store a translation with the key `hello` and value `bonjour`. *However-* we might choose to deploy other structures. Another example might be `origin=my_happ` `translated=en-UK` storing `welcome_field=Hello`; and a separate DNA containing `origin=my_happ` `translated=fr-FR` storing `welcome_field=Bonjour`. This to illustrate that we can make translations-of-translations and setup various structures around areas where translation has been given less attention.

The "registering the translation zome" aspect of this is really just a broadcasting feature to enable unserviced participants of an application a network space for launching and discovering translation alternatives.

The end result would be that participants in an application with an interest in having it translated into their locale would become the owners and maintainers of their translation data within that app.

There are other applications toward translation of application *content* (rather than interface *code*) that could be serviced simply by using dot-notation to describe alternative translations for other records down to the field level (eg. storing `economic_event.aed9fd9asd7990.name` with an alternative-language version of that field).