Improve user defined string translation: caching and performance

The current user defined string translation (i18nstrings) throws a new query for each new string to translate. This may be slow for pages with too many translatable strings. Some options to avoid this may be:
- Use the i18n_strings table (which is currently populated but not used) for preloading big chunks of strings, like all translations for terms in a vocabulary.
- Use full caching for some textgroups, like content types or profile fields and categories
- Implement array translations. Some function that may take an array of strings to translate, that may be loaded with a single query.
- Autocomplete fields for localized vocabularies may use new queries which load the translation along with the terms.