This was testing that a signature inconsistency occurs, but this now manifests as a db inconsistency which can't be used as a test expectation because specific tuple numbers are liable to change with the environment.
Pros:
* <obinit> no longer emitted: one less function per class
* Parameters to the primary constructor, if any, are no longer referred to out of scope
* Simple primary constructor `val` and `var` declarations work as expected
Cons:
* If there are multiple secondary constructors, no primary constructor and long init blocks, there could be considerable duplicate extraction of those init blocks. Hopefully this case is very rare.
This happened because setting the type context for the return-type part of a function's label meant that the label now matches Java <-> Kotlin, and therefore it gets a Kotlin-source source location.
