Avoid unnecessary parens in some generated SQL

This makes three separate but related changes to remove extra
parens.

When creating complex expressions with an arbitrary number of
arguments, strip off any NOOP expressions.  This will allow
things like AND(foo, NOOP(AND(bar, baz)) to combine into
AND(foo, bar, baz).

When using Sequel.& and related methods, in the single argument
case, return the argument directly if it is already of the
correct class.  If the single argument is not already of the
correct class, wrap it in a NOOP.
Add Dataset#paged_each :strategy=>:filter option for increased performance

This new strategy makes #paged_each not use offsets, but instead use
filters based on the last retreived row to implement the paging.
Using this new filtering approach is signficantly faster than using
the previous offset approach.  In simple testing:

                indexed     unindexed
100000 rows        7.3x          4.1x
200000 rows       13.4x          4.6x
300000 rows       19.9x          4.6x

Unfortunately, determining when this approach is safe to use is
difficult.  In SQL, identifiers appearing in the ORDER BY clause
can be aliased in the SELECT clause, and the ORDER BY clause can
refer to either the identifier or the alias, and they can be
ambiguous (SELECT a AS b, b AS a FROM c ORDER BY a, b), and I'm not
sure if all databases handle the rules per the SQL standard (it
would surprise me if so).  It's also possible to order on columns
not being selected, in which case you can't get the values for the
last retrieved row.  Also, if the value for any of the column values
for the last retrieved row are NULL, you can't use a filtering based
approach.

Basically, there are too many corner cases to turn this on by
default, which is why it requires manually specifying the option.

To handle nontrivial cases, when using the :strategy=>:filter option,
you can also provide a :filter_value option proc.  This proc takes
the last retrieved row and an array of order by expressions, and
should return an array of values in the last retrieved row related
to those expressions.  The default is to guess at the symbols used
and just look in the hash for them, but that can fail in some of the
cases mentioned above.
Add Dataset#paged_each :strategy=>:cursor option in the postgres adapter

Cursors are the fastest way to implement paging.  The postgres
adapter already has a use_cursor method for using cursors
(predating the introduction of paged_each), this just integrates
the two so that you can get a cursor implementation using the
paged_each API.
Add Dataset#use_cursor :hold option in the postgres adapter for supporting cursor use outside of a transaction

This can be useful for long running cursors that don't need
to see a consistent view of the database, and where keeping
a transaction open may negatively affect performance.
Add Dataset#where_current_of to the postgres adapter for supporting updating rows based on a cursor's current position

This should be the fastest way to update a large dataset where you
need to update individual rows because the logic for how to update
the rows is in the application and not the database.
Add Database#create_join_table? and #create_join_table! for consistency