Evaluate alternative solutions for terminology storage

Currently terms are stored in the DB, which means:

• A new term needs to be added from Django Admin. That's painfully slow.
• Do-no-translate terms rely on the entity not being created, so it doesn't show up in the project for translation and it's filter in the terminology search API.
• Notifications are not sent when we add new terms (that's #2562)

One other limitation is that we cannot only store only translation for each term. In some case, it would be nice to have alternative spellings, especially for longer strings (e.g. "add-ons" is "componenti aggiuntivi" in Italian, but can be shortened to "comp. aggiuntivi" where necessary).

TBX supports multiple translations for a term in one language (<termSec>).

My original thought was to use a standard VCS repository, and Fluent as storage. But things get complicated:

• Need multiple fields, so semantic comments.
• Need to manage multiple translations for one string (variants?).

So, maybe we should work directly with TBX, adding support in moz-l10n for parsing/serializing, and store that in a repository?
That would solve the notification problem, and would make adding new terms a lot easier than doing it one at a time in Django Admin.

Downsides:

• Setting up an instance becomes harder. To support terminology, they would need to set up a repository.
• We probably need a special flag for the terminology project.
• We need to support TBX in moz-l10n.

No files or tests are named. Start by reviewing the current terminology storage and Django Admin flow, then compare the proposed repository and TBX approach with moz-l10n's stated parsing and serialization needs. Done means a documented storage decision, including handling comments, multiple translations, notifications, and instance setup.