Refactor ResultSetConsumer and related contracts

Currently, a ResultSetConsumer implementation itself is needs to iterate over the result set. Or, if it just expects exactly one result, it must raise an exception. All this logic should be pushed to the methods like JdbcConnection#query().

A fluent API would be nice, reducing the number of query methods on JdbcConnection:

query("select from...")
    .statementFactory(...) //optional
    .prepare() // optional
    .consumeWith(consumer) // OR mapWith()
    .mapWith(mapper)
    .singleResult() // OR resultList()
    .resultList()

That's just a quick draft, but it demonstrates the general idea.

The notion of result set consumer should also be challenged: it might be justified sometimes, but there are many cases in the code base, where currently a consumer is used to modify some variable as a side-effect (typically, a reference or AtomicXyz), which should better be done using a mapper and simply returning the value.

This also should take into account SqlServerConnection#singleResultMapper(ResultSetExtractor<T>, String) and its counterpart in the Db2 connector.