Fixed race condition during presentation compiler restart

* In the former implementation, if a request to restart the presentation compiler
  was executed while the presentation compiler was being initialized, the reset request
  could get lost. This was the reason for flackyness of the hyperlinking test
  `HyperlinkDetectorTests.test1000656`. The new implementation has much stronger semantic,
  and, among others, it guarantes that:

  1) `askRestart` requests are never lost.
  2) If a call to `apply` is executed *after* and `askRestart`, the execution of the `apply`
     is guaranteed to be performed after the presentation compiler is reinitialized.

  In general, I believe this new implementation guarantees happens before semantic (see
  http://en.wikipedia.org/wiki/Happened-before).

* Revert "Retry `HyperlinkDetectorTests.test1000656` flaky test"
  This reverts commit 35091aebfa2785a192742407003ce1064b20a784.

* Created a `ScalaPresentationCompilerProxy` that is responsible of handling the presentation
  compiler's lifecycle. Furthermore, this new abstraction allows for further refinements. For
  instance, we could introduce the logic for automatically shutting down a presentation compiler
  when is not being used (the net effect would be to reduce the memory footprint when a user
  has several opened Scala projects).

* Deleted `Cached` as it is now superseeded by `ScalaPresentationCompilerProxy`.

Fixes #1001880
Never shutdown the presentation compiler in the middle of a test run

If you want to reinitialize the state of the presentation compiler,
`askRestart` should be called instead of `shutdown`. The reason is that when
calling `shutdown`, the presentation compiler dumps all queued work items, and
this can lead to lost updates.

On the other hand, for test isolation reasons, it is absolutely fine to
shutdown the presentation compiler *before*/*after* a test is executed.
Removed uneeded locking in `ScalaProject.failedCompilerInitialization`

The reason why we were using the instance locking was to avoid showing several
times the message dialog that occurs when the presentation compiler fails to
initialize.

If you look closely, you will notice that the lock is simply used to make sure
the update of the field `messageShowed` is atomic. Therefore, it is only
natural to replace the lock usage with an `AtomicBoolean` whih has very handy
operation for atomically setting its content, and returning the old value.