Spelling.
Fix: comparing strings with == .
Remove memcaching of individual counters.

The whole CounterGroup is memcached anyway, and will be read whole
from the datastore on any cache miss.
Utility functions to read and write a CounterGroup.
Put reading and updating of group inside the update group transaction.

I don't know that there is any point in a transaction that only
protects the datastore write and not the corresponding read (and
therefore the updates in between).

I leave the operation of collecting the memcache sharded increments
out of the transaction.  These are not idempotent and it would be
tricky to keep this correct in the face of retries.  Just leaving
any concurrent increments to be handled in the next persist cycle
maintains correctness and is much simpler.
Make Dao's ShardedCounterManager an instance member.

The CounterGroup static ShardedCounterManager was being cached in
the `group` member and never refreshed.  This was OK when we were
double-caching the counters, but upon removing that, it would
cause counters to always stay at their initially loaded value.

An option to fix this would be to intrusively invalidate the
Dao.COUNTER_MANAGER.group from the PersistController.  That would
be an ugly violation of modularity and thread unsafe (what if
group was deleted after one thread had called loadGroup() but
before it was done with the `group` member?).

This solution costs us one memcache read per instance of Dao we
create.  We'll see whether that is a performance problem.
Add comments as to why we aren't using `persistedCounters`  with memcache.
Wrap remaining mutating Dao methods in transactions.

This is actually a bigger deal than it sounds.  Some of these are
being called on every available event, which often come duplicated,
and unhandled collisions may effectively undo any other concurrent
modification to the affected LanternUser.