Syncronizing scroll positions after edits is inconsistent

[Col-E]

Most of it is hacky wait 300ms then scroll

Instead we should have a pending actions queue and when the representation is ready to display the class then we can process the queued actions. This should make scrolling to items instant as soon as they're ready which should reduce the visual jank described in #25

The ClassRepresentation and FileRepresentation implementations should implement this behavior.

[Col-E]

An alternative solution, is to do something like the following:

while (virtualized.getEstimatedScrollY() != targetY) {
	// Use a latch so we don't create a back-up when queueing up FX threads.
	CountDownLatch latch = new CountDownLatch(1);
	Threads.runFx(() -> {
		virtualized.estimatedScrollYProperty().setValue(targetY);
		latch.countDown();
	});
	// Wait on the latch to complete, or continue anyways after a few milliseconds and try again.
	// Should give the app time to update the estimated Y property so we don't loop more times than
	// we need to.
	try {
		latch.await(15, TimeUnit.MILLISECONDS);
	} catch (InterruptedException e) {
		// Ignore
	}
}

We won't be busy waiting due to the latch, and we should be able to queue up immediate scroll actions. If one goes through and fails to update the scroll position, another one is immediately queued (can limit the number of times this occurs to prevent inf loops)

With a bit of testing, this shows almost no jitter most of the time.

[Col-E]

Latches in general would be a good idea for lots of behavior actually.... 🤔

[Col-E]

I'm pretty happy with the new version so far. Will investigate if users report issues.