NoMatchingViewException leaks view hierarchies until test suite finishes

### Description

While a test suite is running, the `AndroidJUnitRunner` thread holds the test suite result in a local variable of type `org.junit.runner.Result` where `Result.failures` is a list of `org.junit.runner.notification.Failure` and each `Failure` has a `Failure.fThrownException` that points to the thrown exception, which here is a `androidx.test.espresso.NoMatchingViewException`. Unfortunately, `NoMatchingViewException` has a strong reference to the root view where the exception was thrown.

This means that while the test suite is running, any test failing due to a view matching error will leak to the corresponding root view being leaked for the duration of the test suite. This increases memory pressure. Developers who run LeakCanary in tests might see subsequent tests fail due to a leak being detected, when that leak is actually caused by the Espresso.

### Steps to Reproduce

* Run a test suite where the first test fails due to view matching
* Add LeakCanary leak detection to a subsequent test, with a configuration to detect leaks in the whole heap dumps instead of just newly leaks in the current tests
* Notice that subsequent tests fail as well.

### Expected Results

* Test infra should not hold on to view hierarchies of past tests, subsequent tests should not fail.

### AndroidX Test and Android OS Versions

All versions of AndroidX Test and all versions of Android.

### Link to a public git repo demonstrating the problem

https://github.com/square/leakcanary/issues/2297

Start by tracing AndroidJUnitRunner's handling of Result.failures and NoMatchingViewException's reference to the root view. Reproduce the described failing test suite with subsequent whole-heap LeakCanary detection. Done means failure handling no longer retains view hierarchies from past tests for the duration of the suite.

Written by the indexing model from the issue text.