Investigate moving from jmockit to something actively maintained

[taylor.smock]

jmockit is no longer maintained. While I don't think it is going to break anytime soon, I do think it is highly likely to break in the next few years. Specifically, it (apparently) uses a customized fork of ASM, and that is highly likely to break at some point.

I'd rather start working to replace it now (when it isn't broken) than have to replace it suddenly when something breaks it.

There was some discussion in #16010 about whether or not we should try using mockito instead of jmockit. Of note:

• jmockit only had one developer who appears to have abandoned the project
  • There is a fork at ​https://github.com/hazendaz/jmockit1 (do we want to use that instead? they've integrated some of our PRs against jmockit and seem to be active)
• jmockit supports "global" mocks
  • We'd apparently have to do a lot of work to get mockito working properly (specifically, we'd have to fiddle with dependency injection)
  • mockito does support thread-local mocks now (apparently), so this might be "good enough" since we really only have three threads we care about most of the time (MainApplication.worker, EDT, and the JUnit thread)
• jmockit supports "private" method mocks (but so does mockito + powermock; powermock isn't supported anymore though)
  • We mostly need private method mocking due to some of our tests hitting UI codepaths. Maybe we should fix those? Maybe with something like BooleanSupplier/IntSupplier for answers to UI questions?

Potential plans of action:

• Add dependency on mockito and start moving tests to it
• Switch jmockit from original author to hazendaz
• Remove need for (most) mocks by adding parameters that will call the UI codepaths in the UI, but otherwise return a specified value

Example of the last point:

public static void combineWays(Collection<Way> ways) {
    // Do stuff
    // Then ask question
    if (ConditionalOptionPaneUtil.showConfirmationDialog(...)) {
        // Finish doing stuff
    }
}
// Versus
public static void combineWays(Collection<Way> ways) {
    combineWays(ways, () -> ConditionalOptionPaneUtil.showConfirmationDialog(...));
}
public static void combineWays(Collection<Way> ways, BooleanSupplier checkConfirmation) {
    // Do stuff
    // Then ask question
    if (checkConfirmation.getAsBoolean()) {
        // Finish doing stuff
    }
}

An important note is that none of the potential plans of action are exclusionary.