Fixes gh-121 (ExpectedException handles JUnit exceptions)

ExpectedException rule no longer handles AssertionErrors and
AssumptionViolatedExceptions by default. This means that the
rule doesn't intercept if your test fails because of an violated
assertion or assumption.

If you want to test assertions or assumptions you have to tell
the rule to handle such exceptions via handleAssertionErrors()
or handleAssumptionViolatedExceptions().
deleted duplicate EventCollector
the two handle... methods are returning the rule

The two methods handleAssertionError() and
handleAssumptionViolatedExceptions() are returning the rule.

Now you can write
  @Rule
  public ExpectedException thrown = none().handleAssertionError();
or
  @Rule
  public ExpectedException thrown = none().handleAssumptionViolatedExceptions()

Thank you David, for this suggestion.
Added MainRunner. This removes the need for public methods in JUnitCore
MainRunner installs a SecurityManager which traps the System.exit(), thereby
removing the need to have runMainAndExit and runMain public in JUnitCore.
MainRunner is only used in the tests of course.
SortMethodsWith allows the user to choose the order of execution of the methods within a test class.

The default order of execution of JUnit tests within a class
is deterministic but not predictable. Before 4.11, the
behaviour was to run the test methods in byte code order,
which pre-Java 7 was mostly predictable. Java 7 (and some
previous versions), does not guaranteee the order of execution,
which can change from run to run, so a deterministic sort was introduced.
As a rule, test method execution should be independent of
one another. However, there may be a number of dependent
tests either through error or by design. This class
allows the user to specify the order of execution of test methods.

There are four possibilities:

MethodSorters.DEFAULT: the default value, deterministic, but not predictable
MethodSorters.JVM: the order in which the tests are returned by the JVM, i.e. there is no sorting done
MethodSorters.NAME_ASC: sorted in order of method name, ascending
MethodSorters.NAME_DESC: sorter in order of method name, descending
Add names for parameterized tests. Fixes #24 and #44.

In order that you can easily identify individual test, you may provide
a name for the Parameters annotation.
 @Parameters(name="my test")
This name is allowed to contain placeholders, which are replaced at
runtime. The placeholders are
* {index} - the current parameter index
* {0} - the first parameter
* {1} - the second parameter
* ... - the other parameters
If you don't use the name parameter, then the current parameter index
is used as name.

Example:
When you use @Parameters(name="fib({0})={1}") with the Fibonacci
example, then you get test names like "fib(3)=2".

This feature is based on the work of Dimitar Dimitrov (pull request
#145).
Thank
you.
Don't use static import for MessageFormat.format
The runner adds the square brackets to the name.
Apply code review.
Use SecurityManager recommended by Stefan Birkner
Don't remove listeners, which throw exceptions (fixes #209 and #395)
RunNotifier.pleaseStop() is now thread-safe
Make ClassRequest memoize the runner.
Creating the runner can be an expensive operation. Other types of requests
are written in such a way that the runner is already memoized.
Merge pull request #370 from matthewfarwell/junit-core-run-fixes

Added MainRunner. This removes the need for public methods in JUnitCore
EventCollector always uses TypeSafeMatcher.
Use the same name as in the test. Fix documentation.
Changes after review by kcooney
Merge pull request #397 from stefanbirkner/removeListener

Don't remove listeners, which throw exceptions (fixes #209 and #395)
Following feedback from dsaff
Merge pull request #386 from matthewfarwell/sortwith

SortMethodsWith allows the user to choose the order of execution of the methods within a test class