Move common rspec dependencies into custom Gemfile

When the example app is created for running cukes we need to setup a
Gemfile. It needs to share the same dependencies as this repo. To
facilitate this, move the common dependencies into a custom Gemfile.

Switch to using the proper bundler `eval_gemfile`, which properly
handles path location differences, instead of reading a file then using
raw `eval`.
Use custom Gemfile with example app.

Without using a custom Gemfile, the main `rspec-rails` repo bundle is
used. Due to how various Rails autoload issues work with bundler, this
caused `RSpec::Support` to be automatically loaded by the rails
generator. The root cause of this is because `rspec-support` and
`rspec-core` are explicitly included in the Gemfile.

This differs in behavior from when a normal Rail's app only specifies
`rspec-rails` in the Gemfile. Setup an explicit Gemfile to resolve the
load difference issues.
Include Gemfile sanity check.

Part of the reason for this not being caught earlier is due to the
gemfile being setup to not require the supporting gems by default. This
creates a few specs to help manage that.
Ensure that we actually create a spec_helper file.
Share the bundler install path.
Extract rails gem loading into shared Gemfile.

When the example app is generated it puts a Rails version that is
defined by currently installed version. This works great in most
situtations, except `master` or other edge branches. The version listed
is the current version of Rails, so they diverge.

Move how we load rails into a custom Gemfile, which we eval ourselves.
We then remove the rails version put into the gemfile and share our
custom version. Due to when `rake` and other shell processes fork, the
RAILS_VERSION environment variable is properly passed through.
Merge pull request #1116 from rspec/backport-smoke-test

Backport smoke task from pull request #1087