Load our adapters and extensions first.

[cupakromer]

Ensure that our adapters and extensions are early in the load process.
This way we can be sure that all adjustments to the Rails libs are
available when we our code that depends on Rails.

[cupakromer]

This has the side effect of early loading ActiveSupport and ActiveSupport:: Concern. Many of the example groups use these features but do not directly require ActiveSupport. This caused an issue in #1242. However, I do not think this PR needs a Changelog entry because of that (see next paragraph).

Right now we have an implicit expectation that the Rails environment is loaded first. It would be good to consider either aborting the spec run or issuing a warning that the environment is not loaded when require 'rspec/rails' is called. I think that would be a breaking change so it should be a config option if we go that route.

On a related note. Many rspec-rails projects have custom setups where they only load parts of Rails. As it stands now, rspec-rails isn't completely setup to support this. It is something I would like to support down the road, but I feel it would require a significant amount of work. It would also require a good documentation update to explain how loading rspec-rails in isolation will work.

[myronmarston]

This has the side effect of early loading ActiveSupport and ActiveSupport:: Concern. Many of the example groups use these features but do not directly require ActiveSupport.

My suggestion is to move away from using ActiveSupport::Concern all together. I don't think it's a big enough win to warrant that dependency. Instead, I think that we can use RSpec core shared example groups for the stuff that currently uses ActiveSupport::Concern. Or just plain old modules.

[cupakromer]

I'm fine with moving away from AS::Concern in the long run. We can modify the existing modules to move away from it as a first step. I'd like use to resolve rspec/rspec-core#1749 before moving these to shared example groups.