SI-6260 Avoid double-def error with lambdas over value classes

Post-erasure of value classs in method signatures to the underlying
type wreaks havoc when the erased signature overlaps with the
generic signature from an overriden method. There just isn't room
for both. But we *really* need both; callers to the interface method
will be passing boxed values that the bridge needs to unbox and
pass to the specific method that accepts unboxed values.

This most commonly turns up with value classes that erase to
Object that are used as the parameter or the return type of
an anonymous function.

This was thought to have been intractable, unless we chose
a different name for the unboxed, specific method in the
subclass. But that sounds like a big task that would require
call-site rewriting, ala specialization.

But there is an important special case in which we don't need
to rewrite call sites. If the class defining the method is
anonymous, there is actually no need for the unboxed method;
it will *only* ever be called via the generic method.

I came to this realisation when looking at how Java 8 lambdas
are handled. I was expecting bridge methods, but found none.
The lambda body is placed directly in a method exactly matching
the generic signature.

This commit detects the clash between bridge and target,
and recovers for anonymous classes by mangling the name
of the target method's symbol. This is used as the bytecode
name. The generic bridge forward to that, as before, with
the requisite box/unbox operations.
SI-6260 Adddress pull request review

  - fix typo
  - remove BRIDGE flag from the method that we promote from
    a bridge to a bona-fide method
  - note possibility for delambdafy to avoid the bridge method
    creation in *all* cases.
  - note inconsistency with anonymous class naming between
    `-Ydelamdafy:{inline,method}`
Merge pull request #3428 from retronym/ticket/6260

SI-6260 Avoid double-def error with lambdas over value classes