Prepare for 2023.3: Move tests using MyMockApplication to unittests (#…

…5421)

If I understand this correctly, the problem existed from the beginning,
it has been revealed by this change:
JetBrains/intellij-community@c973850#diff-4497b4c4afdd25574053db8b6de01a43669c1b3200a5d4d31d14da002614e400L956

In the old IntelliJ versions, if I understand correctly, the tests were successful because
1. Some of the intergration tests were spawning the original non-mock application
2. The non-mock application was scheduling the DaemonCodeAnalyzerImpl's runUpdate
3. The non-mock test has finished
4. Then the mock-based tests has started
5. A mock-based started and installed MyMockApplication to ApplicationManager
6. The DaemonCodeAnalyzerImpl's job was still running and it scheduled ApplicationManager.getInstance().invokeLater()
7. As MyMockApplication was already installed, it handled the invokeLater call
8. DaemonCodeAnalyzerImpl's runUpdate called ApplicationManager.getApplication().assertIsDispatchThread()
9. But in MockApplication, the assertIsDispatchThread() method is implemented as empty, so nothing was crashing

Since the commit c973850dd, the dispatch thread assertion is not delegated to the Application any more,
but it is done by ThreadingAssertions.assertEventDispatchThread, which is not implemented in MockApplicaion,
hence it really checks whether the thread is EDT.

For this reason, we would like to separate all tests relying on MyMockApplication from the ones relying on
the real Application. This would not solve the race fully, but at least it wouldn't lead to a case where
a task scheduled by real Application is run by MockApplication

java/BUILD

@@ -149,6 +149,7 @@ intellij_unit_test_suite(
         "//intellij_platform_sdk:truth",
         "//proto:proto_deps",
         "//shared",
+        "//testing:lib",
         "@com_google_guava_guava//jar",
         "@junit//jar",
     ],