Add "safe" database cursors

The old db.cursor() way of fetching an unlimited cursor still works, but
this is now called an "unsafe" cursor.

A "safe" cursor is returned by the new functions db.readonly_cursor() and
db.updating_cursor().  The former can only execute SELECT queries.  The
latter must be called with a list of table names that the cursor can
update using UPDATE, INSERT INTO and DELETE queries.  An updating cursor
can also execute SELECT queries, but no other.

The db.updating_cursor() function actually returns a context manager
object that returns the actual cursor when entered.  Upon exit, the
transaction is automatically committed or rolled backed, depending on
whether an error occurred.

Nesting of updating cursors is not allowed.

Safe and unsafe cursors can be mixed, but if an unsafe cursor has made
updating queries (anything but SELECT) then creating an updating cursor
fails until the transaction is committed or rolled back.  If an unsafe
cursor is used to make an updating query while an updating cursor is
active, the transaction is rolled back rather than committed.  Manually
committing a transaction while an updating cursor is active fails.

Currently, this mechanism is only used in the new API implementation,
which only performs SELECT queries currently, and now only does so using
read-only database cursors.