#KT-22804 Fixed

(cherry picked from commit a194eb9)

Remove a non-reflective usage of the ResourceSet class, which has been
moved to a different package between versions. Access it through
reflection instead. This is a workaround. We can introduce a proper
fix once we have a public API in the Android plugin.

The test case that could detect the compatibility issue is
`testAndroidExtensionsManyVariants` (it uses experimental Android
extensions), but we did not run it with 3.2.0-alpha6. This commit
adds a test class with the same tests for 3.2.0-alpha6.

Issue #KT-23192 Fixed

(cherry picked from commit 0039be6)

(cherry picked from commit 7d72fe0)

Note that this is EP used in another plugins (ex. LivePlugin https://plugins.jetbrains.com/plugin/7282-liveplugin)

(cherry picked from commit 82481b4)

May be used to add additional repository to all projects

Fix KT-22205 and https://issuetracker.google.com/issues/71556313

Hitting breakpoints in Kotlin JUnit test with an Android Gradle
project sometimes(*) does not work in Android Studio 3.1 beta.

(*) The issue is related to various threads running concurrently
with "dumb" mode background code, so the issue reproduces only
on certain configurations.

In a nutshell, the issue is as follows

* On one hand, gradle build finishes, fires an event ("buildFinished")
  that is processed "later" and that causes the IDE to enter "dumb" mode
  for a shot amount of time (about 300-500 msec on a somewhat up to date
  multi-core computer).

* On the other hand, once the JVM of the debuggee is started, breakpoints
  need to be resolved (on the debugger thread, through a call to
  com.intellij.debugger.engine.CompoundPositionManager.createPrepareRequests.
  This code calls into the "KotlinPositionManager.createPrepareRequests",
  which in turns calls into "PerFileAnalysisCache.analyze". That method
  returns "AnalysisResult.EMPTY" is the project is in dumb mode.
  This return value prevents callers from successfully resolving
  the source location into a breakpoint.

Given that the 2 code paths above execute on separate threads without
explicit synchronization, the "failed to resolve breakpoint" issue
occurs sporadically, to the point it happens 100% of the time on
certain configuration.

The fix is so wrap the kotlin breakpoint resolution code inside
a "runReadActionInSmartMode" so that the debugger thread "waits"
for "dumb" mode to terminates before trying to resolve breakpoint
locations.

 #KT-22205 Fixed

(cherry picked from commit 94ee78c)

^KT-23371 Fixed

(cherry picked from commit c7513b5)