Add junit5 support (#690)

* Refactoring: extract class building methods.
* Move imports to import providers.
* Switch to new TestFramework implementation with TestFrameworkDefinition
delegate. Handle ignoring tests correctly in JUnit5.
* Implement handling JUnit5 rules.
* Add tests for JUNIT5.
* Update docs.

fixes gh-489

docs/src/main/asciidoc/verifier_introduction.adoc

@@ -15,7 +15,7 @@ produced by Spring Cloud Contract Verifier.
 * Messaging routes, if you're using a messaging service. We integrate with Spring
 Integration, Spring Cloud Stream, Spring AMQP, and Apache Camel. You can also set your
 own integrations.
-* Acceptance tests (in JUnit or Spock) are used to verify if server-side implementation
+* Acceptance tests (in JUnit 4, JUnit 5 or Spock) are used to verify if server-side implementation
 of the API is compliant with the contract (__server tests__). A full test is generated by
 Spring Cloud Contract Verifier.
 
@@ -363,8 +363,8 @@ mode for HTTP contracts. However, JAX-RX client and explicit HTTP invocations ca
 used. (To do so, change the `testMode` property of the plugin to `JAX-RS` or `EXPLICIT`,
 respectively.)
 
-Apart from the default JUnit, you can instead use Spock tests, by setting the plugin
-`testFramework` property to `Spock`.
+Apart from the default JUnit 4, you can instead use JUnit 5 or Spock tests, by setting the plugin
+`testFramework` property to either `JUNIT5` or `Spock`.
 
 TIP: You can now also generate WireMock scenarios based on the contracts, by including an
 order number followed by an underscore at the beginning of the contract file names.

docs/src/main/asciidoc/verifier_messaging.adoc

@@ -69,8 +69,8 @@ messaging configuration, so you only need the one annotation.
 === Publisher-Side Test Generation
 
 Having the `input` or `outputMessage` sections in your DSL results in creation of tests
-on the publisher's side. By default, JUnit tests are created. However, there is also a
-possibility to create Spock tests.
+on the publisher's side. By default, JUnit 4 tests are created. However, there is also a
+possibility to create JUnit 5 or Spock tests.
 
 There are 3 main scenarios that we should take into consideration:
 

docs/src/main/asciidoc/verifier_setup.adoc

@@ -245,8 +245,8 @@ from the Groovy DSL should be placed. By default its value is
 `$buildDir/generated-test-sources/contractVerifier`.
 * *stubsOutputDir*: Specifies the directory where the generated WireMock stubs from
 the Groovy DSL should be placed.
-* *targetFramework*: Specifies the target test framework to be used. Currently, Spock and
-JUnit are supported with JUnit being the default framework.
+* *targetFramework*: Specifies the target test framework to be used. Currently, Spock, JUnit 4 (`TestFramework.JUNIT` and
+JUnit 5 are supported with JUnit 4 being the default framework.
 * *contractsProperties*: a map containing properties to be passed to Spring Cloud Contract
 components. Those properties might be used by e.g. inbuilt or custom Stub Downloaders.
 
@@ -582,8 +582,8 @@ classes.
 use Spock classes, the class is `spock.lang.Specification`.
 * *contractsDirectory*: Specifies a directory containing contracts written with the
 GroovyDSL. The default directory is `/src/test/resources/contracts`.
-* *testFramework*: Specifies the target test framework to be used. Currently, Spock and
-JUnit are supported with JUnit being the default framework
+* *testFramework*: Specifies the target test framework to be used. Currently, Spock, JUnit 4 (`TestFramework.JUNIT` and
+6JUnit 5 are supported with JUnit 4 being the default framework.
 * *packageWithBaseClasses*: Defines a package where all the base classes reside. This
 setting takes precedence over *baseClassForTests*. The convention is such that, if you
 have a contract under (for example) `src/test/resources/contract/foo/bar/baz/` and set