[SLC] Drop regular declarations shadowed by boxed ones

Symbol light classes materialized both the regular declaration and the
one requested by @JvmExposeBoxed whenever a value class was involved,
without checking whether the two end up with the same JVM signature.
Java resolve was then offered duplicate candidates that cannot coexist
in a class file: `ExposedResult` got two `consume(Result)` methods, and
`Test(StringWrapper?)` got a private regular constructor next to the
public exposed one with the very same descriptor. Compiling the
fixtures and reading `javap` confirms that the backend emits a single
declaration in both cases.

Boxing normally does change the signature, so both declarations have to
stay. Only two shapes collapse, and the JVM backend special-cases each:

- `kotlin.Result` is the only value class excluded from name mangling,
  and a nullable one is already mapped to `kotlin/Result`, so nothing
  tells the two methods apart unless @JvmExposeBoxed renames the boxed
  one - see `acceptsNullableResultWithoutRenaming`;
- a constructor cannot be renamed, so it is distinguishable by its
  parameter types alone, and a nullable value class leaves nothing to
  box - see `isBoxedInlineClassType`.

Mirror these two rules rather than compare computed JVM identities: an
identity comparison disagrees with the backend both ways. Keyed on the
name and the parameters it would also drop `int jvmMemberLevel()` next
to `IntWrapper jvmMemberLevel()`, which the backend keeps; keyed on the
return type as well it would keep a regular constructor taking the
unboxed `String` of a nullable `StringWrapper`, which the backend never
emits. Mirroring is cheaper, too: parameter types are already inspected
on this path, and the new check runs only when both declarations are
otherwise required.

The `resultNullable`, `constructorBoxed` and `dataClassWithValueClass`
goldens lose their duplicates and now agree with their `.lib.java`
counterparts. New fixtures pin the boundaries: `resultNullableVariable`
for accessors, where only a receiver, a context parameter or the
property type of a setter can clash; `resultNullableMangled` for a
nullable `Result` accompanied by a mangling value class, a non-null
`Result` or a non-null type parameter; `constructorBoxedMixed` for a
constructor that still has something left to box; and
`jvmNameResultNullable` for @JvmName pulling a return-type-mangled name
back onto the boxed one.

Drop the problem description that tracked this divergence.