I recently worked on explicitly breaking reference cycles to
prevent objects from leaking when we mix garbage-collected
Kotlin objects with reference-counted Swift objects.

But this work was likely to regress because we didn't have a
mechanism to prevent these reference cycles from recurring.

This PR introduces a bunch of machinery to explicitly test
for reference cycles. It works on the JVM because that's a
capable platform for this kind of dynamic analysis, and
because it's consistent with the Kotlin/Native platform that
is actually where we need to defend against for leaks.

The first new class is JvmHeap, which lazily inspects an object
for its outbound references. This correctly captures the Kotlin
compiler-inserted indirect references. It also includes lots
of special cases to avoid traversing into implemnetation details
of kotlinx.serialization and coroutines.

The second new class is CycleFinder, which is a basic Dijkstra
breadth-first search. It's one neat feature is that it can
reconstruct the list of properties that participate in a cycle.
The cycle in LeaksTest (before the widget is removed) is:
     * callHandler
       * endpoint
         * inboundServices[3]
           * value
             * service
               * viewOrNull
                 * mutableListChildren
                   * container[0]
                     * onChange
                       * receiver
                         * eventSink
                           * delegate

This PR adds a test for widgets leaking. In a follow-up PR I intend
to add tests for other interfaces and extension points in Redwood that
can be implemented in Swift. This includes event listeners, Zipline services,
TreehouseContentSource, and CodeListener.