Presentation Compiler should not reload managed units while keeping the lock

While restarting the presentation compiler, all units managed by the restarted
presentation compiler are (re)loaded in the new presentation compiler.
However, doing so while holding the `pcLock` can lead to a deadlock, as it can
be observed in the stacktrace reported in the ticket #1002003.

The proposed solution is move the reloading of the compilation units managed by
the restarted presentation compiler *outside* of the synchronized block. This
prevents the deadlock from happening. Unfortunately, this change also introduces
a new race-condition, as it is now possible that the compilation units loaded in
the restarted presentation compiler may be loaded in the new presentation
compiler, if two restart requests are executed concurrently. This is definitely
an issue, but I don't see how we can fix this problem on our side (my sentiment
is that we may be able to fix the problem by changing the initialization
contract in the presentation compiler).

Related to the above, it is worth noting that a similar race condition can
already happen even without the changes proposed in this commit. For instance,
all requests queued in a presentation compiler can get lost if the presentation
compiler is restarted before the queued requests have been served.

Fix #1002003
Fix #1002007
Fix #1001943
Fix #1001911
Re #1001880
Re #1001875
Merge pull request #639 from dotta/issue/pc-deadlock

Presentation Compiler should not reload managed units while keeping the lock