Write persistable data storage system for the bot

In a fashion of prematurely-abstracted OOP, write a generic bot
data/state storage system and a subclassed persistent data storage
implementation.

 * ``StorageController`` manages ``StorageHandler``s.
 * ``StorageHandler``s handle ``StorageContainer``s.
 * ``StorageContainer``s store the actual data in question as object
   attributes.

Subclass ``StorageHandler`` and ``StorageContainer``:

 * ``PersistableStorageHandler`` handles and persists to storage
   containers that can be persisted. The current implementation uses
   simple pickle load/dump (and gzip on top of pickled file), but
   this can be easily changed / subclassed.
 * These persistable containers are ``PersistableStorageContainers``
   (which are nothing more than plain objects with an attribute that
   holds their name.)

The idea was to have a generic storage system that can be adapted to
various use cases; e.g. have ephemeral object store that securely
wipes its contents upon release/shutdown; have different kinds of
persistent storage; etc.
Make bot's state controller use new storage system

Write a simple bot data/state controller that, when passed a master
``StorageController``, creates a persistable storage handler, and
adds two persistable storage containers:

 * "user_access_times" for the churn controller
 * "user_challenges" for the challenge-response system
Write helper functions for storage & churn control

 * gpDump() saves object to file and gzip()s it
 * gpLoad() loads gzip()ed file to object
 * round_float_to_int() rounds a float to nearest int a bit better
   than int(round())
(Re)write a simple effective churn control system

Use new persistent storage for storing user access times.
Hash user handles and round up timestamps.
Update core bot to use new churn, state & storage

 * initialize and use ``StorageController`` and ``TwitterBotState``
 * use churn control when processing bridge requests; persist state
 * set up and handle SIGTERM signals to
   * properly stop Twitter stream listener
   * make ``StorageController`` properly close the storage handlers
Write a simplistic challenge response system

Write a generic challenge response system/controller which makes
use of persistable storage. Write a pretty bogus simple text-based
challenge-response to be used for testing.

Make the bot use the CR system. The way they work together is ugly.
``BridgeRequest``s + the storage handlers will make them non-ugly;
this is next.
Test out initial Twisted reactor based CR; etc.