Breaking this up

- KILL_WORKER is just for testing, so we can instantiate AnalyticsMessages in tests.

- mHandlerLock exists because we change the reference to mHandler - a null mHandler indicates a dead AnalyticsMessage. So, the state that changes is the move from non-null to null for mHandler, we can't synchronize on mHandler because it goes away- we need something else that never changes to hold the lock. We could use an AtomicReference to this, but we do other work as well (in particular, deleting the DB in KILL_WORKER, or just quitting the looper when the AnalyticsMessage thread dies due to misadventure) that could have us wind up in an inconsistent state if we didn't gate it.

- We quit the Looper that's serving the handler, but I'm not sure we can call Handler.quit()