Major file refactor; Doc does not match code.

The tests pass, but I haven't touched the text at all (except for the
__all__ test, which I had to change), and there's a lot more refactoring
to do in the sqlite_pickle_db.py file.

We are now back to a package.  I have a non-trivial __init__ file (it
contains all of the algebra) because I don't want the names of the rel
and row classes to have an extra level in them.  This is perhaps a silly
reason, but it also makes logical sense to me: what is in the __init__
file is the "base API", and what is in the other modules is selectable
pieces of the extended API.
Fix intro for doc split, other minor edits.

Including adding the Tutorial D example for the scalar type
definition, which I see I missed adding before.
Beginnings of DB API test infrastructure.

The infrastructure needs to be more robust, but I think I'm
going to defer that until later.
Drop checks for leading '_' in names.

Like the read only header stuff, a check like this is really against the
Python "consenting adults" philosophy, and having it already led to some
awkwardness in the code (internal-only "_name_check" argument).  Better
to just drop it.
Best of both worlds: Database->dict, keeping r.

At first I was going to just drop the r attribute, because it was an
ugly hack.  Making the Database a dictionary was a no-brainer once I
thought of it (the existence of '_iter_rels' was a big clue).  When I
started rewriting the doc in terms of dictionary access, though, I was
sad.  So instead I converted r into *just* a relation-as-attribute
access method.  The whole thing is much cleaner now, I think.
Keep sqlite_pickle_db name space clean.
PersitentRelation, and display as method.

This clears up that pesky little XXX comment in _display that
I ought to improve that if statement.  It also sets the stage
for a lot of what should be coming later.

Note that I have not yet done a sweep for places in the algebra or
docs where I'm using type(r)() and should be using rel(r.header)().

Also note that I don't know why the repr for a PersistentRelation class
is 'dinsd.PersistentRelation instead of
'sqlite_pickle_db.PersistentRelation', but I'm ignoring that question
for now.
Pointer to key on keyed relation.

This was a bit of a rabbit hole, as it revealed that I hadn't
thought about the fact that closing the database leaves the db
relation objects intact if there are references to them.  So now
I invalidate them on close by changing their __class__.

Also fixed up some wording per previous refactorings.
Use [] instead of getattr consistently.
Use ChainMap instead of copying row __dict__.
Basic transaction infrastructure.

Also fixed my references to current_thread to be function calls,
(I need actual threading tests!), and commented out the key
constraint implementation because we still need some additional
infrastucture to make that actually work.
Transaction namespace, make namespaces nestable.
Key constraint improvements, not done yet.

Need still more infrastructure.
Use threading.local correctly in ns contextmanager.

I don't know what I was thinking when I implemented the ns context
manager, but I was very wrong.  Reimplemented it using threading.local
correctly (still no threading tests, though).  I also was thinking wrong
when I wrote that the namespace got used as globals; it doesn't, it is
part of locals, so we can indeed use a ChainMap.  We lose the attribute
notation for putting things in the namespace, but since namespaces
elsewhere in Python are dictionaries, this is probably actually a good
thing.

Not sure if I'm going to fix transactions next, which has the same
problem, or if I'll write threading tests.
Add a thread safety test for ns context manager.
Use threading.local correctly in transactions.

Generalized the _NS class a bit.  The transaction code is now
much simpler.
_NS _current_->current.

_current_ was left over from when I thought I could still use
attribute style assignment into the namespace.
Pre-compile the expressions.

We could also use a compiled expression cache.  Using compile
is enough of a premature optimization, though :)
Make db changes visible inside transaction (only).

This __getitem__ implementation feels a little hackish, but it works,
without having to employ locks.  Note that my example doesn't prove that
the persistent DB is actually updated.  I'm not sure how/where I want to
add those tests.

I also don't have a test of two transactions (as opposed to one
trans and one non-trans) not interfering, but I think I'll only add
such a test if there proves to be a bug there someday, since for any
implementations I've thought of this one should be the more important,
and sufficient, test.
Make key constraints work.

They still aren't saved.  This is, what, a month and half since I had to
take a detour to write the infrastructure mentioned in the now deleted
comment?  Maybe I'll be able to simplify this later when I understand
everything better.