Massively optimize ->cursor->next while fixing some bugs along the way

Massively optimize ->cursor->next while fixing some bugs along the way

Cursor access was previously wrapped in a dbh_do() block with the intent to
restart the connection and the cursor upon a handle error. However this
arrangement overlooks our inability to restart the cursor from the same
spot (or for that matter guarantee the same dataset). Instead we remove
the dbh_do wrap entirely, and just let the exception propagate to whatever
esle might be ready to catch it (and potentially properly retry the select).

As a side effect (because anonsubs are sloooooooow) the end result
yields astonishing speed gains - one of the test cases mentioned in [1]
went (on my test rig) from 9.61058 to 0.64960 due to this commit alone.

A particular detail - the cursor private methods _dbh_next/_dbh_all are no
more as they are unused indirection now. All storage drivers (well their
respective cursors) have been adjusted, but not yet tested due to lack of
a proper environment.

[1] http://lists.scsys.co.uk/pipermail/dbix-class/2012-July/010595.html