Test against Rails 4.0.0
Fix TU1/2 adapters to avoid 'undefined Test::Unit::TestCase'
Including a shim adapter now just re-runs the autohook

The autohook already injects an adapter into the appropriate test
framework which is available when the autohook runs. There is no need to
create shim adapter modules because they could easily conflict with real
adapter modules.
Guard adapters from being double-loaded
Completely re-write integration tests

So there are a few issues with the integration tests currently.

The way that integration tests are written right now is full of magic.
Basically the way it works is, if you want to support a test framework,
you create an example group or test case, you mix in either
AdapterTests, AdapterIntegrationTests, or TestUnitTests, and then to
supply the tests which are specific for that test framework, you
override very specific methods. As the module you're mixing in supplies
the tests being run, some of the methods you override configure those
tests, and some methods even supply the body of those tests. These
methods are interesting in their own way because in them you actually
BUILD A STRING of Ruby code -- this code gets injected into a generated
test file which will get run automatically. Generating this test file is
complex because there are all sorts of various conditions we have to
test. What if we want RR required before the test framework? What if we
want it required after? What if we don't want the test framework
required at all? What if there are other things that need to be
required? These are things that should be easy to set and accomodate
for, and they're not.

The other thing is RSpec and TestUnit integration tests share the same
set of tests. This is fine except that for the RSpec tests we have to
take those tests -- which, as TestUnit is the lowest common denominator
here, are test_* methods -- and convert them to it { … } blocks. We also
have to fill in shims for assert_* methods. It's just gross code and
it's something we shouldn't have to think about.

Another thing is that the Rails tests don't actually test against a real
Rails application. Sure, we're generating a project that requires Rails,
but it's not the same as generating a real Rails application, using
`rails new` and all that. It doesn't simulate real-world conditions.
This is especially evident in the Cucumber integration tests, which
don't even try to run `cucumber`, it copies the implementation of
`cucumber` (which will of course be a false positive if the
implementation of `cucumber` changes).

Finally there are too many test suites. There's no reason to have a
proper minitest test suite in order to test Minitest, for instance -- if
we generate real projects with real test files we can test whatever we
want all inside of an RSpec test suite.

So this is a large commit, but it basically replaces all of the
integration test file with versions that are more readable and allow for
more flexibility. How is this achieved, you ask? Well, I built a whole
generator system that can produce either a Ruby project or a Rails
project with support for various test frameworks. There is a LOT more
code here than before, but all of it exists in order to make a more
accurate simulation. Also, adding support for a new test framework or
modifying existing tests will involve a lot more copying and pasting,
but I don't anticipate doing this often, so it doesn't matter so much to
me.
Remove Gemfile.lock

Now that certain dependencies in Gemfile are dependent on the current
Ruby version we can no longer keep the lockfile in version control.
Target jruby-1.7.4
Use custom formatters for RSpec 1 and 2

The main goal of these formatters is to ensure that output is flushed
constantly as it is produced. The reason for this is to ensure that
output shows up immediately on Travis and does not get buffered (Travis
will kill a build if it doesn't see output for 10 minutes).
Add missing integration tests
New way of running/defining test suites

The list of test suites which show up as available Rake tasks is now
governed by spec/suites.yml. You can modify this file to control how
those test suites are run (supply ENV or args to the spec runner). This
file is also used to generate .travis.yml (and there's a Rake task
that you use to do this now).
Update .travis.yml to define a custom build matrix
Update README and FOR_DEVELOPERS [ci skip]
Update changelog [ci skip]