Do not install semantic highlighting on a "bad" `ScalaClassFileEditor`

As it turns out, there are currently two ways that a `ScalaClassFileEditor`
can get instantiated:

1) The "standard" way is via the `ScalaClassFileProvider`, which will make sure
   that a `ScalaClassFile` is created if and only if a source attachment can
   be found for the passed classfile. (As a side note, we should create a
   `ScalaClassFile` independently of the fact that a source attachment can be
   found, and that is actually the reason why I filed Re #1001926 - have a look
   at the ticket to understand the current implementation is wrong).
   The `ScalaClassFileProvider` is called by
   `ClassFileProviderAspect.classFileCreations` which intercepts creation of a
   JDT classfile to return a scala classfile when appropriate.

2) The other way is via an Eclipse extension point (`org.eclipse.ui.editors`).
   It is less clear to me when this gets used, but it is the one responsible of
   allowing the creation of a `ScalaClassFileEditor` with an underlying (Java)
   `ClassFile` instance, instead of the expected `ScalaClassFile`. Ideally, we
   should prevent creating an instance of `ScalaClassFileEditor` with something
   that isn't a `ScalaClassFile`, as this breaks the assumptions made in this
   class (in fact, the `ClassCastException` reported in this ticket is due to
   the fact that we expect `ScalaClassFile` and cast it to a
   `InteractiveCompilationUnit`). However, it isn't clear to me how (and if) we
   can achieve this (maybe, we are just hitting a limitation of our architecture,
   since we build the Scala support on top of the Java one). As a side note,
   simply removing the declared extension point doesn't work. Hence, the workaround
   I've implemented is to not hook semantic highlighting if the underlying class
   file isn't a `ScalaClassFile`. Despite it is not a perfect solution, it seems
   like a good workaround.

Fixes #1001925