SNOMED language and localisation support.
There are four ways to consider locale in SNOMED CT.
1. A crude language label (e.g. "en" in each description.
   This should generally not be used.
2. Requesting using one or more specific language reference sets.
   This provides the most control for clients but the burden of work
   falls on clients to decide which reference sets to use at each request.
3. Request by a dialect alias.
   This simply maps aliases to specific language reference sets.
4. Request by IETF BCP 47 locale.

Options 1-3 are defined by SNOMED.
Option 4 provides a wrapper so that standards-based locale priority strings
can be used effectively.

Arguably, there are two separate issues. For clients, they want to be able
to choose their locale and this should use IETF BCP 47. For any single
service installation, there will need to be a choice in how a specific
locale choice is met. 

A backing key value store implemented using LMDB.

LMDB has very fast read access, which makes it highly suitable as hermes
operates principally in read-only mode. We use netty's direct buffers, and a
shared pool because of allocation overhead compared to on-heap buffers.

We use the key value store in one of two ways. The first is to store entities.
These are usually keyed by the identifier, except for descriptions, which are
keyed by a tuple of concept identifier and description identifier. That
optimises the common fetch of all descriptions for a given concept. The second
is to store null values as part of an index, with compound keys. This means
we can rapidly iterate across a range of keys, which are always sorted, and
stored big-endian. The compound key structures are defined below.

It would be possible to create a generic key-value protocol, but this instead
contains domain-optimised code.

Members creates a Lucene search index for reference set members.

Search creates a Lucene search index for descriptions.

Optimised hand-crafted serialization of SNOMED entities.

Store provides access to a key value store.