Use checkstyle to forbid JUnit 3 and some other internal packages.

Fix for #106 and more

Example checkstyle messages:
```
[ant:checkstyle] D:\...\glide\...Test.java:10:1: Import from illegal package - sun.internal.HackyReflectionClass. Programs that contain direct calls to the sun.* packages are not 100% Pure Java.
[ant:checkstyle] D:\...\glide\...Test.java:11:1: Import from illegal package - org.mockito.internal.matchers.Matches. Use org.mockito.Matchers to instantiate argument matchers; or org.hamcrest.Matchers for assertThat.
[ant:checkstyle] D:\...\glide\...Test.java:14:1: Import from illegal package - junit.framework.Assert.assertEquals. Tests are written in JUnit 4, use org.junit.* equivalent.
```

Example assertion errors achieved by using JUnit 4's assertThat and hamcrest-library Matchers.

To produce the error: commented out the `harness.doLoad();` line
```java
assertThat(harness.runners, hasEntry(equalTo((Key) harness.cacheKey), notNullValue(ResourceRunner.class)));

java.lang.AssertionError: 
Expected: map containing [<Mock for EngineKey, hashCode: 436418>->not null]
     but: map was []
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:865)
	at org.junit.Assert.assertThat(Assert.java:832)
	at com.bumptech.glide.load.engine.EngineTest.testRunnerIsPutInRunnersWithCacheKeyWithRelevantIds(EngineTest.java:384)
```

To produce the error: multiplied transformedAspectRatio by 100 making 10 -> 1000
```java
assertThat("nearly identical aspect ratios", transformedAspectRatio, closeTo(originalAspectRatio, 0.05));

java.lang.AssertionError: Expected nearly identical aspect ratios
Expected: is a numeric value within <0.05> of <10.0>
     but: <1000.0> differed by <989.95>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:865)
	at com.bumptech.glide.util.TransformationUtilsTest.assertHasOriginalAspectRatio(TransformationUtilsTest.java:99)
	at com.bumptech.glide.util.TransformationUtilsTest.testFitCenterWithSmallWideBitmap(TransformationUtilsTest.java:42)
```

To produce the error: multiplied width by 100 making 13 -> 1300
```java
assertThat("width", width, lessThanOrEqualTo(maxSide));

java.lang.AssertionError: width
Expected: a value less than or equal to <500>
     but: <1300> was greater than <500>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:865)
	at com.bumptech.glide.util.TransformationUtilsTest.assertBitmapFitsExactlyWithinBounds(TransformationUtilsTest.java:106)
	at com.bumptech.glide.util.TransformationUtilsTest.testFitCenterWithSmallTallBitmap(TransformationUtilsTest.java:67)
```

To produce the error: subtracted 1 from both width and height
```java
assertThat("one side must match maxSide", maxSide, either(equalTo(width)).or(equalTo(height)));

java.lang.AssertionError: one side must match maxSide
Expected: (<499> or <49>)
     but: was <500>
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.junit.Assert.assertThat(Assert.java:865)
	at com.bumptech.glide.util.TransformationUtilsTest.assertBitmapFitsExactlyWithinBounds(TransformationUtilsTest.java:106)
	at com.bumptech.glide.util.TransformationUtilsTest.testFitCenterWithSmallWideBitmap(TransformationUtilsTest.java:41)
```
This is definitely a nit, but we should be consistent about using ``is()``. You've used it above (in GlideDrawableImageViewTargetTest) but not here. I'd lean toward always using it whenever it semantically makes sense, but I don't feel strongly about it.