Changing how the select_count method counts returned rows.

[jwoertink]

Fixes #686

This new way now allows for counting against more complex queries which include using distinct_on. The main reason for this is using pagination when you have these complex queries.

Before this PR, you couldn't do this:

get "/messages" do
  pages, messages = paginate(MessageQuery.new.distinct_on(&.status))
  html IndexPage, messages: messages, pages: pages
end

This would throw an error that status needs to be in a "GROUP BY" or used in an aggregate function. But of course, if you added status to a group, it would also want id, and you'd still have to change the count from COUNT(*) to COUNT(status) or something else...

Also as @wyhaines pointed out in 686, there's several cases where this method is actually faster than the previous. All of the queries I tried seemed to perform about the same speed if not faster.

[jwoertink]

This could be cleared up if we implemented #682

[jwoertink]

You can now use a limit and offset in the select_count queries. The reason you couldn't before was because SELECT COUNT() would always ever return 1 row. So it didn't make sense to have a limit or offset. Now with this sub-select way, you can use limit to your advantage.

Say you have a table with 7 records in it. If you do a limit 10, and then run a count, you'll get 7. Do the same thing once there's 12 records in the table, and then you'll only get 10. It's sort of like an upper bounds check.

[robacarp]

I like this. I run into this problem in Postgres a lot.