Avoid Adding Duplicated JUnit Entries on Classpath

[dnestoro]

Fix for: #305

[melix]

I am a bit confused by this issue. IMO, the version of JUnit declared by users should take precedence. This means that whatever JUnit version we need should only be needed at compile time of native build tools, not runtime. So it's probably a dependency scope mistake (implementation instead of compileOnly). We shouldn't rely on dirty tricks to remove jars by hand from classpath.

[melix]

@sbrannen @sdeleuze We need your inputs in order to accept or reject this PR. In order to fix this issue, we had to make several changes to dependencies. In particular, the junit platform native project is now compiled against one version of JUnit (whatever NBT wants to use), but will not "leak" these dependencies to consumers, so that they can use whatever version of JUnit they prefer (which may be a downgrade).

While this works, this is a breaking change, because now consumers have to add the junit-platform-launcher dependency to their projects in order to run native tests, similar to how we changed our own tests. Is this acceptable?

Second, and more problematic, our code depends on Junit Platform legacy reporting. I have no idea why this code is here, because our tests seem to show that it works well without. Therefore, what we've done is simply catch the error at runtime, and avoid failing if junit-platform-reporting is not on classpath. If it is required on a user project then the dependency would have to be added explicitly. We haven't found a condition that we could use to display a warning if the dependency is missing (we don't want to warn if it's redundant).

Any ideas?

[sdeleuze]

Let's discuss that in our next meeting.