Add SQL script for SQL-based event store.

So folks don't have to reverse-engineer it from the code.
Bring command handler and aggregate together.

The split in the original starter kit was largely about lifetime, as
command handlers were "forever". However, it's possible to get the
same set of benefits and simpler code by bringing the two together.

By moving command handlers into the aggregate itself, they can now
look directly at the state to uphold invariants, which removes some
of the ceremony. It *does* leave the programmer to keep the handlers
"focused", however. Note that they still yield events.

Various other things get simpler as a result. BDDTest requires only
one generic parameter, as does IHandleCommand - a nice boilerplate
reduction. The ever-uncomfortable Guid? goes away in Aggregate and
also in IEventStore and its implementations, simplifying both by a
good amount.
Move one-aggregate queries to the aggregate.

To get a feel for how this works out. The read model, predictably, is
a bit simpler because it now only cares for inter-aggregate queries,
which cuts down on the amount of information held in the aggregate it
has to duplicate. For example, price is unimportant in inter-aggregate
queries, so item prices disappear from the read model.

The aggregate gets a little more involved; it has to track a few more
bits so it can answer the queries. However, it was not painful, nor a
great deal of extra code.

Of course, now we know that viewing a tab is immediately consistent,
and so could relax the event dispatch to subscribers to take place
asynchronously and likely have no bad effects on user experience.