add sqlite3 lib dependency

Switching from the fully in-house catalog to a real database, sqlite.
This will provide full consistency, even across reboots, and will still
allow the ability to do in-memory databasing if needed.
add comment to REMOVE KEY

Remove key, keys do not need to be hierarchized.  They are sent as their
literal string dkey form with the pipes and all.  Everything can be a
literal set of keys in a relatively simple sqlite database.
switch to full sqlite system

todo:  test and optimize, make sure that datapoints are ordered right,
work in a system for expiry of old datapoints (probably fully within
sqlite).
catalog:  wildcard expansion

Todo:  The same things as the previous update, plus the wildcard
expansion should actually return the wildcards.  There are better ways
to do this, so we might want to do that.
Catalog:  Dissociated dkey retrieval from datapoint retrieval

Now datapoints can ONLY be grabbed by one distinct DKey at a time.  This
makes easier the process of grouping datapoints by dkey for retrieval.
The dissociation of DKey allows for dkeys to be sorted separately in a
different table under a hierarchical model, for wildcard matching and
retrieval, instead of this messy shell-based globbing.
Next, the variable/wildcard dkey retrieval (while dkeys are still associated with
individual datapoints as well, for regular retrieval) needs to be stored
into a different table with keys that are NOT pruned for hierarchical
searching and matching, for the GetDKey routines.
Catalog:  add full dkey searching with wildcard functionality

New dkey table, new hierarchical sorting system, new lookup system
(similar to the old system with wildcard fields), new match structure
for datapoints

lookup system for dkeys with wildcard functionality is disgustingly
inefficient.  It needs some good tuning.  It's also not necessarily
robust.  I don't know how it will handle trying to find nonexistent
fields, but it should be alright.