Sharing GenBcode backend between scalac and dotty

This PR abstracts GenBcode implementation classes from existence of global using forwarders, which would have a different implementation in dotty.

The main class here is BackendInterface that defines everything that backend uses.
While it would be good to have backend use less that 150 methods on `Symbol` this commit doesn't address this issue: it tries to not introduce any changes in behavior.

In order to not loose perfromance and not allocate options during pattern matching this implemtation relies on name-based pattern matching with preallocated objects, this makes BackendInterface non-thread safe, but as of now it is used only in single thread. If several threads will ever be used to transfrom AST to asm bytecode than each of threads will need to own its own instance of BackendInterface.

@lrytz please have a look.
As I mentioned before, I'm not so happy that symbols get new extension methods in the backend. I think we should restrict the methods here to those that are actually members of class Symbol. For the others (like `getsJavaPrivateFlag` etc) I'd prefer if they were just ordinary methods that take the symbol as parameter.

For the cases when a method is a member on scalac's symbol class, but not in dotty's, i think it would be better to opt for an ordinary method too, instead of an extension method in the `DottyBackendInterface`, for the same reason.