Fix for issue where counter_culture_fix_counts skips rows and erroneously sets counts to 0

Say we define something like this on our `Member` model:

````ruby
belongs_to :parent
counter_culture :parent,
    column_name: Proc.new {|m| m.condition? ? 'members_count' : nil },
    column_names: { ['members.condition = ?', true] => 'members_count' }
````

When we run `Member.counter_culture_fix_counts` we get a counts query like this:

````sql
SELECT parents.id, COUNT(members.id) AS count
  LEFT JOIN members ON parents.id = members.parent_id WHERE members.condition = 't'
````

id  | count
------------- | -------------
1  | 15
&nbsp;  | &nbsp;
3 | 10

You'll notice that row number 2 gets skipped entirely, because the `WHERE` is applied to the outermost `SELECT` instead of the `JOIN`. (Row 2 didn't have any members where `condition` is `true`)

We compare the results of that counts query to our existing data, which runs its own query returning this result:

| id  | members_count |
| ------------- | ------------- |
| 1  | 999999  |
| 2  | 999999  |
| 3  | 999999 |

When we try to compare those counts with the existing counts, we get a row where our counts hash has a nil value, which is fine, because it will be set to 0. The results:

| id  | members_count |
| ------------- | ------------- |
| 1  | 15  |
| 2  | 0  |
| 3  | 10 |

Say, however, we are doing this in batches, with batch size of 2 (for the purpose of this explanation). Our 'count' query returns this on the first batch:

id  | count
------------- | -------------
1  | 15
&nbsp;  | &nbsp;
3 | 10

However, our main query returns this on the first batch:

| id  | members_count |
| ------------- | ------------- |
| 1  | 999999  |
| 2  | 999999  |

And then this on the second batch:

| id  | members_count |
| ------------- | ------------- |
| 3  | 999999 |

Which causes 3 to be compared to nil (since the batches are out of sync) resulting in this:

| id  | members_count |
| ------------- | ------------- |
| 1  | 15  |
| 2  | 0  |
| 3  | **0** :worried:  |

Sad face.

## The Fix

What I've done, ultimately, is moved the conditions into the innermost join. (I iterated through a couple fixes to ensure that edge cases were being covered, but the final code diff should be self-explanatory.)

The final query (based on the one above) would look something like this:

````sql
SELECT parents.id, COUNT(members.id) AS count, parents.members_count
  LEFT JOIN members ON parents.id = members.parent_id AND (members.condition = 't')
````

| id  | count | members_count |
| ------------- | ------------- | --- |
| 1  | 15 | 9999 |
| 2 | 0 | 9999 |
| 3 | 10 | 9999 |

(Notice that `count` and `members_count` are returned in the same query now. This ensures that the batches always remain in sync. Also, there is simply no reason for two queries on the same table.)

I also added a test case which hits the large batch + condition case. I made sure it failed on the current codebase and passed after my changes. (All other tests pass of course).

### One last thing to consider

This *may* be a breaking change for a few people who rely on the fact that the conditions used to be applied to the outermost `SELECT`. (Say, for instance, you attempt to select for rows that match tables other than the one being counted).

None of the examples or test cases seem to care about this, and for the sake of avoiding complexity I think this is a reasonable trade-off. If you disagree, I have an alternate approach which may solve the problem, but it requires a second, slower query, and puts extra load on the database in order to obey the batch_size constraint. (To see that solution, take a look at 82ce7dd -- it runs a second 'inverse' query which looks for all parent objects with ID not in the matching count query, and sets their counts to zero.)