Stop preloading vr module to avoid racey crash

It was possible for the vr split to be loaded in the background thread
before the application ClassLoader had been replaced with the chrome
ClassLoader. This was causing issues in the BundleUtils logic which
makes sure ClassLoaders have the correct parent. For now, we will just
disable vr preloading entirely since it is safer for merging to stable,
but we should be able to preload safely after the application
ClassLoader has been replaced.

(cherry picked from commit ec49b04)

Bug: 1184300
Change-Id: I87461e1093d1acbd47c11a7dfed8e44598a9234e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2733370
Commit-Queue: Clark DuVall <cduvall@chromium.org>
Commit-Queue: Andrew Grieve <agrieve@chromium.org>
Auto-Submit: Clark DuVall <cduvall@chromium.org>
Reviewed-by: Andrew Grieve <agrieve@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#859594}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2733374
Reviewed-by: Krishna Govind <govind@chromium.org>
Cr-Commit-Position: refs/branch-heads/4435@{#3}
Cr-Branched-From: f3c257e-refs/heads/master@{#859168}

chrome/android/java/src/org/chromium/chrome/browser/base/SplitChromeApplication.java

@@ -124,8 +124,6 @@ public void runImmediatelyInBackgroundThread(Context chromeContext) {
 
             @Override
             public void runInUiThread(Context chromeContext) {
-                // When installed, the vr module is always loaded on startup, so preload here.
-                sSplitPreloader.preload("vr", null);
                 // If the chrome module is not enabled or isolated splits are not supported,
                 // chromeContext will have the same ClassLoader as the base context, so no need to
                 // replace the ClassLoaders here.