GenBCode tightens code before serializing classfiles

Before writing classfiles with "optimization level zero"
(ie -Ybackend:GenBCode) the very least we want to do is remove
dead code beforehand, so as to prevent an artifact of
stack-frames computation from showing up, the artifact described at
  http://asm.ow2.org/doc/developer-guide.html#deadcode

That artifact results from the requirement by the Java 6 split verifier
that a stack map frame be available for each basic block,
even unreachable ones.

Additionally, for dead-code elimination to be effective,
each multi-jump chain should be collapsed to target its
final destination via a single jump. Details in:
  - scala.tools.asm.optimiz.JumpChainsCollapser

Just removing dead code might leave stale entries
(ie pointing to LabelNodes removed during dead-code elimination)
in LocalVariableTable as well as in the exception-handlers table,
thus `EssentialCleanser.cleanseMethod()` also gets rid of those.
The classes in charge of that are:
  - scala.tools.asm.optimiz.LabelsCleanup
  - scala.tools.asm.optimiz.DanglingExcHandlers
GenBCode: test built-in dead-code elimination

The GenICode-counterpart to this functionality was added in
commit b50a0d811f0fb99ccbc295741e66bab348b3f99e to fix SI-7006

As for GenBCode, the documentation says it all:

/*
 * Detects and removes unreachable code.
 *
 * Should be used last in a transformation chain, before stack map frames are computed.
 * The Java 6 verifier demands frames be available even for dead code.
 * Those frames are tricky to compute, http://asm.ow2.org/doc/developer-guide.html#deadcode
 * The problem is avoided altogether by not emitting unreachable code in the first place.
GenBCode: test built-in jump-chains collapsing

Code that contains redundant jumps usually arrives to both
GenASM and GenBCode, for a variety of reasons. To name a few:

  - test/files/run/private-inline.scala after -optimize

  - virtual pattern matcher (for an example see the test in this commit)

The backend(s) manage to get rid of the redundant jumps, for example:

  - GenASM, using collapseJumpOnlyBlocks()

  - GenBCode, using JumpChainsCollapser

The test case in this commit shows how GenBCode reduces
the number of GOTOs from 22 down to 7.
GenBCode: test removal dangling exception handlers

An asm.tree.MethodNode includes a list of exception-handler entries,
each such entry includes (among the other things) start and end
LabelNodes to demarcate the range being protected.

  - Any executable instruction other than NOP means the
    exception-handler-entry should stay.

  - Otherwise, asm.optimiz.DanglingExcHandlers removes
    the exception-handler entry in question.
pretty-printing of ASM ClassNode, MethodNodes, and instructions as well
SI-6759 fixed in GenBCode but beware, it remains open for GenASM
GenBCode: pipelined class building and class writing

Traversing a ClassDef to build an ASM ClassNode requires typer and
therefore must run single-threaded.

However, bytecode transformers that manipulate ClassNodes
don't need typer and thus can run in parallel.

Two other activities that don't depend on typer either are:
  - encoding ClassNodes into the byte array representation of a classfile
  - writing classfiles to disk

The activities above (building ClassNodes, encoding, disk writing)
are performed in different threads (for now, "encoding" is only lightly
loaded, but in the future certain optimizations will run there).
GenBCode turned on by default