dev/translation#67 - Define "Translation" entity. Add during installation/upgrade.

dev/translation#67 - Define "Translation" entity. Add during installation/upgrade.

This creates an entity, `Translation` (`civicrm_translation`), to represent a single translated database value. Loosely speaking,
any field in the database can be designated as translatable -- and then it will be permitted to store values like:

```sql
INSERT INTO civicrm_translation (entity_table, entity_id, entity_field, language, string)
VALUES ('civicrm_event', 100, 'title', 'fr_FR', 'La nouvelle chaine')
```

This is based on a `civi-data-translate` strings table, but with some changes:

* Entity names are usually singular, but `String` is conflicted. I previously used hybrid
  String/Strings (depending on context), but we negotiated `Translation` on tcon.
* The language only needs 5 characters (NN_nn).
* Consolidated `bool is_active` and `bool is_default` into one `int status_id`.
* Added indexing
* Mark dynamic foreign key

This commit includes the BAO with some of the backing-methods required for
API exposure.  However, the API won't really work until we have the
validation-values event, so the API has been kicked to a subsequent PR.

The list of translatable entities/fields will be signficant because it will
determine when/how to redirect data in API calls.  This patch does not
commit to specific translatable fields - but it does provide a hook to
determine them.

When the API PR becomes unblocked, it will include test-coverage that hits the API, BAO, and hook.