detecting what are to become "really static" classes after being tagged @reallyStatic

This commit tracks "really static" module classes. A follow-up commit will add support for "statification" proper (a transformation performed on-the-fly by GenBCode for "really static" module classes and their usage sites).

A "really static" module-class fulfills four conditions:
  (0) marked @reallyStatic
  (1) the module-class is a static module
  (2) the module-class is direct subclass of AnyRef
  (3) the module-class extends either no interfaces or just marker interfaces
bug fix, GenBCode
typos, detecting really-static classes
performing "statification" for @reallyStatic module-classes and member usages-sites

"Statification" is a transformation performed on-the-fly by GenBCode for "really static" module classes and their usage sites.

A @reallyStatic module-classes has all of its members (for example, extension methods of a custom value classes) emitted bytecode-level static, EXCEPT those members overriding methods in the Object API. The reason for this is that some clients may invoke those methods on the singleton (viewed as an object) and expect the overriding implementation to be dispatched.

Additionally, @reallyStatic also results in invokestatic callsites for what used to be invokevirtual callsites with the singleton as receiver, ie the singleton is not loaded anymore before any arguments are loaded.

There's an interplay with @inline methods in an @reallyStatic module-class: the inliner gets permission to have an `invokestatic` (targeting the method in question) replaced with its body, thus potentially skipping running the class-initializer for the associated module-class.
more documentation for reallyStatic annotation