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 obviously doesn't work, as there
   would no editor defined for scala classfiles. Hence, the workaround I've
   implemented is to not hook semantic highlighting if the underlying class file
   isn't a `ScalaClassFile`.

By the way, the issue could be reproduced by copying a **Scala** classfile in the
root of a project, and then trying to opening it would lead to a `ClassCastException`
and an error prompt displayed to the user.

Fixes #1001925