…nit-integration.

The idea is to have this new notifier responsible for firing the PowerMockTestListener events. The JUnit-runner will still be responsible for firing the core JUnit-events to this new notifier - but the extra information necessary for proper composing and firing of PowerMockTestListener events will be fed through the new static utility GlobalNotificationBuildSupport!

…hancements for two purposes...

 1) Make test-class static initializer and constructor send crucial details (for PowerMockTestListener events) to GlobalNotificationBuildSupport so that this information can be forwarded to whichever facility is used for composing the PowerMockTestListener events.
 2) Removal of test-method annotations as a mean to achieve test-suite chunking!

…e AbstractTestSuiteChunkerImpl able to hand over some responsiblities to TestClassTransformer

…n-Powermock stuff taken care of by a JUnit-runner of your choice - or by one of JUnit's default runner-implementations.

On top of the obvious benefit (PowerMock-features in combination with other JUnit runners) this could also help future maintenance of PowerMock as potential new JUnit features no longer need to be reproduced in any additional PowerMockJUnit4xRunnerDelegateImpl-class. E.g. PowerMockRunnerDelegate-usage will result in (unconscious) support for JUnit-rules as long as JUnit-4.7 or later is on classpath, even though the mechanisms around the PowerMockRunnerDelegate-annotation know nothing about JUnit rules!
This is a solution where PowerMock stays in the background and deals with PowerMock-specific stuff whereas the general JUnit stuff is handed over to JUnit's defult runner - or another runner that is specified by the annotation PowerMockRunnerDelegate.
The mechanism is triggered by adding the PowerMockRunnerDelegate-annotation on the test-class - or by running the test with JVM system-property "-Dpowermock.implicitDelegateAnnotation=true"

…plicit usage of the mechanisms around the new annotation "PowerMockRunnerDelegate"

…g tests with system-property "-Dpowermock.implicitDelegateAnnotation=true" - used to cause a test failure with the reasonable message "No runnable methods".

The failure was fired by JUnit's default runner. This trivial problem was solved by making TestParent abstract.

…st-suite.

E.g. org.powermock.examples.dom4j.AbstractXMLRequestCreatorBaseTest would otherwise fail when run with system-property "-Dpowermock.implicitDelegateAnnotation=true" because of the class-loader's VIP-treatment of package-names that start with "org.powermock.".
The special treatment of "org.powermock."-classes is necessary for Powermock to work properly. This problem occurs because some of the demo tests in PowerMock's test-suite is in such a package as well. The quick solution was to treat "org.powermock.examples.*" packages just like any other packages. This is of course an ugly workaround but the other obvious solution (more classes in test-suite to other packages) is also kind of ugly.

…nisms around the PowerMockDelegateRunner annotation allow integration with many different JUnit-runners.

Many of the tests are remakes (more or less) of tests from Powermock agent/rule test suites.

…wermockRunnerDelegate