fix usage of asserts where order or condition is missleading

[carstenartur]

What it does

junit asserts generate an error message based on the parameters presented. So when the fixed part and the actual part of an equal assertion is wrong it creates a wrong message about what was expected. The assertion still "works" because in an equal comparison the order does not matter regarding the failure of the junit test but the error message is wrong.
Another case is when you do the comparison inside of an assertion to check for true. That way junit is inable to generate a useful error message.

This PR fixes some of these issues. It has been generated by using the "Autorefactor" cleanup at
https://github.com/carstenartur/AutoRefactor/tree/master
Afaik this cleanup will not make it into jdt.ui any longer.

I looked at it while checking what could help to migrate tests to junit5.
Since the change was applied to no longer support old java versions in a lot of code of jdt.ui test environments are a mess with wrong name for the testenvironment to be used.

How to test

Nothing should change but the messages should be better in case of an issue.

Author checklist

• [] I have thoroughly tested my changes
• The change is following the coding conventions
• I have signed the Eclipse Contributor Agreement (ECA)

[jukzi]

the build failed multiple times (build 4, 5) with

java.lang.AssertionError: 
Wrong bundles loaded:
- org.eclipse.jdt.junit
 expected:<0> but was:<24>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.eclipse.jdt.text.tests.PluginsNotLoadedTest.pluginsNotLoaded(PluginsNotLoadedTest.java:278)

[jjohnstn]

the build failed multiple times (build 4, 5) with

java.lang.AssertionError: 
Wrong bundles loaded:
- org.eclipse.jdt.junit
 expected:<0> but was:<24>
	at org.junit.Assert.fail(Assert.java:89)
	at org.junit.Assert.failNotEquals(Assert.java:835)
	at org.junit.Assert.assertEquals(Assert.java:647)
	at org.eclipse.jdt.text.tests.PluginsNotLoadedTest.pluginsNotLoaded(PluginsNotLoadedTest.java:278)

This test has been failing randomly for me in PR runs lately before this patch.