Use require instead of load with test/unit/version

  Other gems also require test/unit/version. When this gem loads the
same file it over writes the constant and causes a warning.
Merge pull request #140 from tmiller/master

Use `require` instead of `load` with `test/unit/version`.

Other gems also require `test/unit/version`. When mocha loads the
same file it over writes the constant and causes a warning.

I tried to reproduce the original problem [1] with more recent
versions of the test-unit and mocha gems, but I ran into a
different exception. This exception was fixed by adding a
`gem "test-unit"` statement before the `require "test/unit"`
statement.

[1] http://floehopper.lighthouseapp.com/projects/22289-mocha/tickets/50#ticket-50-13
Make auto-activation of Test::Unit integration more resilient.

This change is specifically to cope with the nasty re-defining of
classes that is done by the `minitest-spec-rails` gem [1]. This
confuses the Test::Unit version detection logic in Mocha and it thinks
that the Ruby 1.8 standard library version of Test::Unit is being used
when in fact there is no Test::Unit version present.

I'm not completely sure why this has reared its head [2] with Rails 4
and/or Ruby 2, and haven't checked carefully that this change is
(a) completely logical; and (b) hasn't introduced any regressions,
but it does seem to fix the problem. I'm going to push it now and try to
track down any regressions separately - I'm pretty hopeful there won't
be any.

Note that it will be possible to avoid this problem in the future
when we introduce the ability to manually activate specific test library
integration and stop using the automatic activation.

[1] https://github.com/metaskills/minitest-spec-rails/issues/17
[2] https://github.com/freerange/mocha/issues/143
Adapt tests to changes in MiniTest output.

The Mocha integration tests are unfortunately dependent on the
exact format of the test results output by MiniTest. This means that
since the format changed in MiniTest v4.6.1, we have to change the
regular expressions used to parse the output.

It would be nicer to use named capture groups for the regular
expression, but these only appear to be available in Ruby >= v1.9.
Safer restoration of stubbed method visibility. Fixes #141.

It is possible for `Module#public`, `#protected` and `#private` to be
redefined on descendant classes, so it' safer to use the original
version of these methods on `Module` when restoring the visibility of
stubbed methods.

Rather than add a completely new set of tests for these scenarios, I
have just embellished the existing tests. It's not ideal, because it
makes it less clear what's going on, but I think it'll do.
Make the `Hooks` module easier to unit test.

Simplify the `Mockery` "API" that is used by the `Hooks` module i.e.
there is no real need for `Hooks` to have direct access to the `Mockery`
instance.
Ensure `Mockery` instance gets reset even if exception raised.

It's unlikely but possible that an exception may be raised in
`Mockery#teardown`. We should ensure that the `Mockery` instance gets
reset if this happens.

I'm not really happy with the way the test works, but without major
changes this is the best I can do for now.

Fixes #144.

I saw this while investigating #142.
Update release notes and bump version to 0.13.3.