[Invariant Fix] Use the same lock inside single GlobalFacade

Before refinement, order of accessing compiler's entities (supertypes,
descriptors, memberscopes) was always the following:

    sources -> libraries -> SDK (built-ins)

With refinement, it is sometimes possible to inverse this order, e.g.
access sources after libraries or SDK. This mainly happens in the following
scenario:

- we reference some library/SDK class, but do not acquire source-lock
  This might seem a bit weird, but actually it is quite easy to achieve
  as soon as we understand that analysis sources doesn't necessarily
  acquires respective lock, only forcing lazy computations does so.
  E.g., we can just traverse PSI tree and meet some refernce to "Any?" -
  this doesn't involves acquiring source-lock

- we start resolving it, which usually involves acquiring library/SDK-lock
  (e.g., in order to get it supertypes or memberScope)

- because we reference it from the source-module, we may like to refine
  it, in which case we will have to acquire source-lock on refinement
  cache

Obviously, that may lead to deadlocks, so, in this commit we disable
creating granular locks when we work with refinement.

Note that if refinement is disabled (which is the case for all non-MPP
projects), we still create separate locks.

core/util.runtime/src/org/jetbrains/kotlin/storage/LockBasedStorageManager.java

@@ -91,6 +91,12 @@ public class LockBasedStorageManager implements StorageManager {
         return getClass().getSimpleName() + "@" + Integer.toHexString(hashCode()) + " (" + debugText + ")";
     }
 
+    public LockBasedStorageManager replaceExceptionHandling(
+            @NotNull String debugText, @NotNull ExceptionHandlingStrategy exceptionHandlingStrategy
+    ) {
+        return new LockBasedStorageManager(debugText, exceptionHandlingStrategy, lock);
+    }
+
     @NotNull
     @Override
     public <K, V> MemoizedFunctionToNotNull<K, V> createMemoizedFunction(@NotNull Function1<? super K, ? extends V> compute) {