Upgrade to Hamcrest 1.3.0 RC2

- Matchers in JUnitMatchers that are now provided by hamcrest-core are deprecated
- Using CoreMatchers where possible

*Important:*
In some but not all cases, this change will cause compiler errors for people
using JUnitMatchers.hasItem(s), both(), and either().
Remove test for functionality provided by Hamcrest
Remove deleted BothTest from AllTests
Simplify matcher expression in ParameterSignatureTest
Remove everyItem matcher now provided by Hamcrest
Deprecate TypeSafeMatcher which is now provided by Hamcrest
assertThat uses org.hamcrest.MatcherAssert

As pointed out by Steve Freeman of Hamcrest, the Matcher interface now
has an additional method describeMismatch. To be safe to catch such 
improvements in the future, MatcherAssert is used instead of
duplicating its implementation.
Update references to Hamcrest JAR
Fix javac build

There seems to be a problem compiling calls of the new

	assertThat(T actual, Matcher<? super T> matcher)

using javac and matchers like `hasItem` and `both` that also use 
`Matcher<? super T>` as parameter.
Merge remote-tracking branch 'KentBeck/master' into hamcrest-1.3

Conflicts:
	src/main/java/org/junit/rules/ExpectedException.java
	src/test/java/org/junit/tests/experimental/rules/ExpectedExceptionRuleTest.java
Replace JUnitMatchers with CoreMatchers
Merge remote-tracking branch 'KentBeck/master' into hamcrest-1.3
Fixes #427 inconsistent javadoc for test rules
The examples for some test rules used

public TestRule chain= RuleChain...

whereas others did not refer to TestRule, they used the class name.
Changed all of those who refered to TestRule to use the class name.
Do we really need to have "GENERATOR" meta for "Microsoft FrontPage 4.0"?
DataPoints need to be Public
cucumber-jvm issue #322, added a new Description factory method and temporarily changed from Serializable back to Object for the unique id; this needs a change to Gherkin
Merge remote-tracking branch 'kentbeck/master'
changed back to using Serializable as the necessary Gherkin change has been made
Fixes #441 fix for issue 283 (recursive temp folders) caused incompatibility
Put back in the method folder.newFolder(String) that
was removed in #283. Tests that the method is there using
reflection.
Changed Enclosed runner to ignore abstract classes. Before this change, an abstract enclosed class caused jUnit to throw an exception.