Refactor counter cache create and destroy

Follow up of #14735 

Move destroy and create counter cache callbacks code inside the `CounterCache` model concern.

The rationale is that the `after_destroy` callback need to access the `affected_rows` variable, and it's cleaner to be in the inheritance chain to access it than to leak it as yet another state on the model.

This refactoring do not move the `update` part of counter caches because Its way more complex and I prefer to do it in another PR.

@tenderlove What do you think?

cc @arthurnn