Fixes rails#18988, rails#22602, rails#23265, rails#28203

*** Description of the problem
So far the counter cached was incremented when one of two things
happened in following scenario.

```
  class Post < ActiveRecord::Base
    has_many :coments
  end

  class Comment < ActiveRecord::base
    belongs_to :post, counter_cache: true
  end
```

1. comment.post = post was called. This would increment the counter
   cache for post in the db
2. Comment was saved with updated post_id and the counter cache is
   incremented in update callback

This solution (especially the fact that we did counter cache increment
in situation rails#1) had few problems:

1. We bumped the counter cache even if in the end the Comment was not
   saved. For example if something like this happened:

```
    comment.post = post
    raise SomeException
```

  then the comment wouldn't have post_id, but post would end up with

2. If someone did the following
```
    comment.post = post
    comment.save!
```

   Post would end up with comments_count = 2 because the counter cache
   would get bumped on both of conditions above.

3. The bump in situation rails#1 was made outside of transaction that saves
the comment which means we would make unnecessary call to db.

4. comment.post = post and comment.post_id = post.id are not consistent.
Former bumps the bumper cache while the latter does not.

*** Solution
This commit removes the counter cache increment on association
assignment. This means that comment.post = post won't bump the counter.
It will only happen when the comment will get saved. This will ensure
more consistency of data in DB.

Other changes that are introduced in this commit:
1. Counter cache incrementer/decrementer can work with foreign_keys
other than the primary_key of the model. That's why methods
updates_counters_for_key, increment_counter_for_key and
decrement_counter_for_key has been introduced.

2. The update callback that bumps counter cache will properly increment
counter cache for polymorphic association even if the only thing that
was changed was type of the related object but it happened to have the
same id as the previously related object.

Notes about chaned tests:
1. In test_belongs_to_counter_with_assigning_nil I changed the models
under test as Comment's post_id is non nullable therefore comment could
never have been saved with post_id = nil. Moreover this test in its
original form shown how flawed the previous behavior of counter cache
was. When nil was assigned to comment.post, that post's comments_count
would get decremented, but in the end it would be possible to save that
comment and it would result in inconsistent data.

2. test_counter_cache_with_custom_column_name - the relation of
SillyReply is basically broken. It uses the same foreign_key "parent_id"
as the Reply (its superclass) topic relation. That's why I used
DogLovers and Dogs for the test of custom names for counter caches.

3. Other tests have been updated to actually save the objects in order
to bump counter cache.