Clean up parallel class loading code and comments

The function SystemDictionary::handle_parallel_super_load is called if another thread is loading a super class of the same class that this thread is loading. It then calls up to resolve_super_or_fail() to try to load that super class, and for some class loaders, waits for the first thread to load the super class.
This is to detect ClassCircularityError on the second thread, and it may have been an optimization (?).

You can generalize this by adding the check for ClassCircularityError directly in resolve_instance_class_or_null and wait in the code that waits for multiple threads to finish loading for this case.

For parallelCapable class loaders that aren't the bootloader, instead of waiting, the second thread will fall through load_instance_class and end up calling load_super_or_null from defineClass, and that has the same effect.

I was trying to write a test case to see if any user code could observe any difference from a parallel thread falling through to load_instance_class (after waiting for the bootloader/non-parallel class loader), vs eagerly calling resolve_super_or_fail to load the super class that the other thread is loading. I couldn't find an observable difference. I'll attach the test case.

We have a fairly exhaustive set of parallel class loading tests (unfortunately not in the open) and many in the JCK tests. All of these pass with these changes.

I also reworded many of the comments so that I could understand them, removed some comments that discussed code no longer there (resolve_from_stream used to create placeholders in some cases), and moved comments closer to the specific code they describe.