[WIP] catch RSpec/ExpectInHook offenses in the setup block

[lazycoder9]

Allow catch RSpec/ExpectInHook offenses in the setup block.
Separate hooks to BUILTIIN and CUSTOM. Custom hooks will be loaded from from AllCops/RSpec/CustomHooks

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Updated documentation.
• Added an entry to the changelog if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

If you have created a new cop:

• Added the new cop to config/default.yml.
• The cop documents examples of good and bad code.
• The tests assert both that bad code is reported and that good code is not reported.

[lazycoder9]

@pirj this is very raw implementation and I've stuck in testing custom hooks. The problem is to avoid changing config.yml file to pass custom hook spec.
I really don't know how to stub or change config file during only one spec.
The main problem is that configuration file is read only once before running specs, which leads definition of all constants (e.g. Hooks::ALL) and keeps them immutable during all specs. Attempts to stubbing constants did not work
I will appreciate if you can tell me possible solution

[pirj]

This might be used somehow to stub AllCops. I believe we'll have to patch it in the long run to accept arbitrary keypairs (that would also allow moving Rails-related code to rspec-rails).
It's ok to use a copy of it now.

This doesn't solve the issue of ALL being pre-calculated though.
What if we take a non-performant way and define ALL as a method that would return BUILD plus fetch from config?

I vote for postponing the decision on how to cache config and be flexible in the specs at the same time.

[pirj]

Closing in favour of #956