Initial commit of draft code for more easily defining content providers.
Factor out new URI matching code for improved testability.

And also because it might conceivably be useful in some other context
on its own...
Basic tests for UriMatcher --- exact matches, with no wildcards.
Tests for string wildcards in UriMatcher.
Tests for numeric wildcards.

Two changes from initial design:

*) Using '=' to designate a numeric wildcard segment, since '#' is
   (correctly) treated by the URI-parsing code as starting a fragment.

*) Not using TextUtils, due to partial Robolectric implementation.
Negative test for attempts to define nonsensical UriMatchers.

Also sneaked in skeletal documentation.
First tests for PositronicContentProvider --- getting content types right.
Basic tests on querying a PositronicContentProvider
More complete specs for PositronicContentProvider query functionality.
Tests for insert/update/delete on PositronicContentProvider.

Nice to know that it works, but comparing the tests to the code,
I start to hear distant echos of DHH's "testing like the TSA"...
First cut implementation of DataStream monad.
Second cut at implementation of the DataStream monad, Duration, etc.

This version takes into account that a data stream's first value may not
be available immediately on creation.  It also defines the combinators
in ways that are, at least, less obviously wrong.  (For example, the
initial value of the stream returned by "someStream.filter( pred )"
will always satisfy the predicate, even if the most recent value of the
underlying stream, at the time of creation, does *not*.)
Tests for DataStream (and tweaks needed to make them pass).
Reimplement our WorkerThread on top of Android's HandlerThread.

I'm somewhat ambivalent about this... it does add overhead.  But it
also makes it possible to have platform ContentObserver post its
observations to one of these (which this change is intended to
allow).
WIP code for observing changes from a ContentProvider.

This is effectively a wrapper for the ContentObserver API, which is,
of course, invoked under the covers.
Factor field management away from scope in BaseRecordManager

The objective here is to support multiple record managers for a given
record type, with parameters (e.g., "parent record ID") --- but isolate
all the donkey work of record management in a RecordDataWrangler, or
something like that, which builds and memoizes all of the field-mapping
data structures once.

(Ultimate cause of this:  trying to deal with a ContentProvider-ized
version of the todo-list app, in which you can't formulate a TodoItem
query without having a particular TodoList ID prespecified, due to
the hierarchical structure of the URLs.  It may be overkill, but we'll
see.  This will all be refactored further anyway; work in progress.)
Add "force" to futures.
Further refactoring in anticipation of "structured repo" record managers.

Deal with the serialization pseudo-handling --- a RecordId needs to be
able to find or reconstruct its RecordManager; allow for subclasses
that reconstruct.
More refactoring:  A RecordWrangler does *not* have an associated repo.

It's the business of other objects to tell it where to put things;
it just handles the donkey work.
Further refactoring:  Scopes refer to a RecordWrangler, not a RecordManager.

For future classes with multiple managers, the manager is the heavyweight
object that should not be duplicated.  Although... manager here is getting
*awfully* thin and indistinct from Scope, which suggests a little renaming
might be in order...