Before this commit, we answered 'no top level class' if Java class finder
could not calculate known class names. However, it's incorrect,
because this situation means 'don't actually know'.
To precise semantics, function name was also inverted
Before this commit, we used FirAccessorSymbol to emulate synthetic properties.
These symbols were generated in Java use-site scope.
Now, we use synthetic scope instead which is above MemberScopeTowerLevel.
This is more performance-friendly and does not require override matching.
However, accessor symbols should be used in situation when Java accessor
overrides Kotlin property which is broken in this commit
(that's why MapEntry test is corrupted here).
Also, we should not create synthetics for pure Kotlin accessors
(that's why javaAccessorConversion test is corrupted here).
Before this commit, we had two methods to do generally the same synthetic thing.
It's an attempt to keep only one of them.
Accessor symbols are generated in Java use-site member scopes,
at this place we know better whether we are in Java class or not.
However, we have to do this at every use-site level, which is relatively slow.
Also we could encounter problems when accessor function is overridden in Kotlin,
and accessor symbol can still contain reference to Java accessor.
Really, this commit implements early J2K mapping for all Java types.
It's questionable and probably wrong at least for super-types,
because, for example, we cannot resolve spliterator() in classes
derived from java.lang.Iterable
Java type enhancement is performed by a special scope kind
Java FIR dump was added for multiplatform tests to look at enhancements
Overrides, J2K mapping, special cases does not work yet
Related to KT-29937
So, for classifiers there are both Symbols and LookupTags
The difference between them is that the former are assumed to have
a reference to the actual FirDeclaration while LookupTags
effectively contain only classId and
something informative may only be obtained by FirSession
#KT-24075 Fixed
Properties aren't implemented yet
FIR symbol provider functions return more specialized types now
Related to KT-28918, KT-29636, KT-29218
#KT-28788 Fixed
Dmitriy Novozhilov