Support passing through messages from alphanumeric senders

Some countries support these one-way SMS senders that come from ascii
alphanum+space senders.  All known SGX pass those through raw as the localpart,
so why not just allow them to and fix it up in Cheogram, since that's our whole
job is to make the SGX author's life easier.

Converts to Base10 (https://wiki.soprani.ca/TextEncodingBase10) and appends a
suitable phone-context.  Don't need to specially handle replies since these are
one-way senders anyway so any reply attempt will fail.  Adds the original
localpart as a nickname so that clients can show it rather than the Base10 gunk.
"Whisper" is an uncommon term of art
Update for network 3.0
Read from redis first, then TC -- write to both

If a key is in redis, use that value. Combine set and hash results from redis
and TC.  All writes go fully to both.

Redis keys are seperated by 0xFF instead of 0x0, the former is actually invalid
in UTF8 so is a fully safe seperator, and has the neat bonus of being used by
CBOR as a terminator (though the usage here does not make the keys valid CBOR).

Hashes are encoded so that we can store (Text, Maybe Text) -- a value of Just x
is stored UTF8 encoded, so if there are no Nothing values the hash looks like a
normal (Text, Text) would.  Nothing is stored as 0xF6, which is invalid UTF8
when alone so cannot be confused with valid text, and is the valid CBOR encoding
of null.

Enum are stored as the text representation of the corrosponding Int.  This is
only used on Bool in the codebase at the moment, so it will be 0 in Redis for
False, 1 for True.  This encoding is pretty common for integers in redis in
DB contains a Redis connection also
Do not assert return value of TC.out
Log errors that happen in adhoc sessions
Show better call stack in byNode error
Guard more uses of byNode more carefully

byNode should die, but until then we should be pretty sure we have a node before
we call it.
Abstract DB

We want to change the storage backend, because we are pushing past the limits of
what is a good idea with TokyoCabinet and have had several corruption events.

So, as a first step, break the hard dependency of the main app code on
TokyoCabinet and instead express the operations in a more abstract data model.
This data model is pretty much based on Redis, which is the intended new storage
driver, but isn't directly tied to that either.
Stop sending welcome message

Even for its intended use case, it often confuses more than it honestly helps.
Clean up many fromString "" to s""
Fix cheogramDiscoInfo

XML attributes do not have an explicit namespace unless prefixed.
Prevent openBinaryFile: invalid argument (File name too long)
Use oldstable in CI for now, since prod does and my desktop does

And new cabal is incompatible
Support xdata-validate:open for list-single

This allows the user to enter any item the matches the datatype as well as
choose from the list.
Put cheogram provided commands last
Send presence request after register