Reorganized & separated get router functionality from summary.py

Added new module get_router.py, and created a handlers package
which will contain all handlers including summary, details, and
bandwidth. Summary.py has been moved to this package.
Added DetailHandler, as well as added more functionality to pyonionoo.

Detail Handler has been added and is working properly along with the
Summary handler. Users can now provide the following parameters for both
handlers: type, running, search, lookup, country. The last three
parameters have not been implemented yet: order, offset, limit. Bandwidth
handler was started but is not finished yet. Note some of the relay information
is incomplete in the detail handler.
Moved summary.py to handlers.
Refactored code and moved filtering functionality to get_router.py.

Code that goes through handler's arguments and filters the routers is
now in get_router.py. As a result, the handlers will now focus solely on
creating their respective documents. Timestamps for relays and bridges
have been added, but more work needs to be done for the bandwidth
handler, as well as some of the fields in the details handler.
Fixed a few bugs.
Phase 1 Complete:

Ensured SummaryHandler is returning JSON to client. get_router.py has been
renamed to database.py and it reads the summary document upon each request.
Next phase entails starting database work and storing the contents in an
in-memory sqlite database.
Created new branch database for Phase 2.
Added sqlite database functionality:

Created a database to store the information of each router according to
the different fields. One table (summary) contains all the fields except
for 'flags' and 'addresses'. A database and the summary table is created
using database(). get_summary_routers() takes in the arguments from
SummaryHandler, reads the summary table, and appends the necessary
routers to a tuple of lists that will be passed back to the SummaryHandler.
'flags' and 'addresses' will be in their own separate tables. The next step
will be to add these two tables to the database.
Consensus weight ordering and additional tables of Summary database have been implemented.

'flags' and 'addresses' tables have been added to the Summary database
in addition to the 'summary' table. Each flag and address have their own
row in their respective tables, but they have corresponding row ids with
their respective router in the 'summary' table. User can now also order
the requested routers by consensus_weight.
In database.py, do all filtering, ordering, etc. through the select
statement.

Made a few other minor refactorings, like having database() return
the connection in order to eliminate the global CURSOR variable.
Main tasks still to do:  externalize request parameter handling to
the handlers module; handle 'search' parameter; have another thread
to create database; transactions on the database.
Deleted remnant global variable CURSOR in database.py.
Externalized GET request parameter parsing.

Added handlers/arguments.py, which has a single function parse.  parse
takes the GET request parameter dictionary as an argument, and returns
a dictionary mapping strings to values.  That dictionary can be used
as the keyword arguments dictionary for the database module functions,
so now the database module does not need to understand anything about
GET requests.
Forgot to delete ARGUMENTS in database.py.
Make the database connection use sqlite3.Row for the row factory.

Having done so, we can now treat each row returned by a SELECT
as a dictionary, with keys equal to the table field names.  This
simplifies the summary handler.

Note that there are also a few comments related to implementing
the 'search' parameter, which still hasn't been done yet.
SQLite database now created at application start, and updated when out
of date.

We have not tested whether transactions are doing the "right thing,"
allowing us to update the database while allowing other threads to
continue reading the "not-yet-updated" database.  And see comments
at beginning of database.py related to using an in-memory database.
SQLite database updated automatically according to a specified interval.

We use a Timer object that updates the database every
database.DB_UPDATE_INTERVAL seconds.  As a Timer, this is not performed
in the main thread, so doesn't block incoming connections.  Happily,
the database update is automatically a single transaction, so the
update is not visible to clients until it is complete.
Deleted some testing files that were accidentally added to the repo.
Application is now non-blocking, using threads.

Each request is handled by a separate thread for querying the database
and assembling the results.  Also fixed the (incorrect) regular
expressions that define the URLs we respond to.
Changed the database update interval to 1 minute from 30 minutes.

In retrospect, a 30-minute interval was silly.
Replaced Python 2.7 string formatting with 2.6 C-style %-formatting.

Pyonionoo needs to run on Python 2.6.