[test] Removes jmockit in favor of mockito

We use mockito in many tests. This removes jmockit which is run as a javaagent in favor of Mockito which is not.

This work is in preparation for applying some static analysis tools, while evaluating others such as Jacoco. I'm also look at ways to improve build times while also decreasing "ramp up time" for contributions from the community. Reducing the number of mock frameworks and dependencies is a step toward that goal.

I'm opening this for discussion. It seems like jmockit was used heavily in GenerateTest in the CLI to test the internals of the generate task. I think this is the wrong approach; each component of that task should be tested in isolation.

I think this approach cleans up the options tests, as it was never really clear to me and most likely to others how to use the Expectations API in jmockit. I also found while testing that the Expectations of jmockit would silently swallow exceptions. For example, scala-http-client defines this method:

public void setModelPropertyNaming(String naming) {
    if ("original".equals(naming) || "camelCase".equals(naming) ||
            "PascalCase".equals(naming) || "snake_case".equals(naming)) {
        this.modelPropertyNaming = naming;
    } else {
        throw new IllegalArgumentException("Invalid model property naming '
                naming + "'. Must be 'original', 'camelCase', " +
                "'PascalCase' or 'snake_case'");
    }
}

The expectation in the test passed modelPropertyNaming as the option and verified that it was executed once. That execution should have resulted in an IllegalArgumentException on invocation, but jmockit's Expectation only cared that the method was called and hid that it was called with invalid data.

I plan to look at replacing the GenerateTest tests with unit tests, and whether it would make sense to construct the Generate class to evaluate argument parsing. The generate task now evaluates that CodgenConfigurator is called as expected. The DefaultGenerator implementation should be tested separately, considering previous tests weren't evaluating anything that was generated.

PR checklist

• Read the contribution guidelines.
• If contributing template-only or documentation-only changes which will change sample output, build the project before.
• Run the shell script(s) under ./bin/ (or Windows batch scripts under.\bin\windows) to update Petstore samples related to your fix. This is important, as CI jobs will verify all generator outputs of your HEAD commit, and these must match the expectations made by your contribution. You only need to run ./bin/{LANG}-petstore.sh, ./bin/openapi3/{LANG}-petstore.sh if updating the code or mustache templates for a language ({LANG}) (e.g. php, ruby, python, etc).
• File the PR against the correct branch: master, 4.3.x, 5.0.x. Default: master.
• Copy the technical committee to review the pull request if your PR is targeting a particular programming language.

cc @OpenAPITools/generator-core-team