- argument type is flexible
- supertype has flexible type argument
- type of expression is more specific than bare type

Also, update error inputs to conform to old FE's

These should have been part of commit 39df3e2b

Also, update error inputs to conform to old FE's

This should have been part of commit 03cb0c3c

Also, update error inputs to conform to old FE's

These should have been part of commit 5167d69b

parameter, since in this case, the compiler generates a bridge, where
the result is unboxed.

since the bridge unboxes it.

 #KT-44141 Fixed

When resolving inline class methods in binary dependencies we look for
methods matching both the new and the old mangling scheme. On the IR
backend the method signature has to be computed for the inline class
replacement, since the logic for signature mangling is not contained in
the method signature mapping, unlike in the old backend.

 #KT-44429 Fixed

^KT-42176 fixed

Take local/anonymous classes and their inner classes into account.
Simplify approximation: use first available super classifier instead
of first super class. This approximation should only happen for
private declarations that were not previously approximated by frontend.
So basically the only requirement for the approximated types is to be
denotable. Note that this only works if the types are not used later.
JVM uses a different string table implementatin as it needs exact
types of private members for reflection.

^KT-20996 Fixed

They used to use the same approximation logic anyway
^KT-20996

Extract the logic of approximating to denotable class supertype
from JS/KLIB and use it in metadata compiler.

^KT-20996 In Progress

 #KT-44140 Fixed

Fixes Kotlin/kotlinx.serialization#1265

Since in 1.5 JVM_IR is enabled by default and supports suspend functions
in fun interfaces, it is safe to enable the feature by default as well.

Dynamically calculating a year is problematic, especially in cases like
FIR where generation happens in every build. When you are working on a
last year's commit, each build creates a bunch of uncommited
 changes of updating the year in copyrights.

This list is backed by mutable list and during iterating on it
we can resolve supertypes of that class via IDE light classes
as IJ Java resolve may resolve a lot of stuff by fir light classes
This causes ConcurrentModificationException

Until `KTI-464 Test tasks with failed tests are cached` is resolved

Because it is more intuitive for end-users.

Type parameters do not necessarily match one-to-one, or preserve order.

Add LightClassUtil.getLightClassMethodsByName to avoid resolving all lightClassMethods and filtration later on

^KT-44322 fixed

Now the same resolve context is used for enum entries and
for constructors.

Before this commit, during the resolve of companion objects we used
the same context than for any nested class. However, during companion
object resolve we should not have companion object receiver itself
accessible in any case (in particular, it should not be accessible
in constructor). So in this commit we introduced separate context
for this purpose.