If it's not within a try/catch/finally, that should be an uncaught
exception path.

^KT-45327 Fixed

To do so, inside the root cause of inapplicable candidate errors,
we will record expected/actual type of receiver, if any.
That will help identifying inapplicable calls on nullable receiver.

Type of a block is a kind of irrelevant for lambdas: their type is much
more complicated and defined via FirDataFlowAnalyzer#returnExpressionsOfAnonymousFunction
at at FirCallCompleter.LambdaAnalyzerImpl#analyzeAndGetLambdaReturnArguments

Update includes:
- Changing syntax of `OI/`NI` tags from `<!NI;TAG!>` to `<!TAG{NI}!>`
- Fix some incorrect directives
- Change order of diagnostics in some places
- Remove ignored diagnostics from FIR test data (previously `DIAGNOSTICS` didn't work)
- Update FIR dumps in some places and add `FIR_IDENTICAL` if needed
- Replace all JAVAC_SKIP with SKIP_JAVAC directive

#KT-39709 Fixed
#KT-43156 Fixed

This commit introduces several different things, in particular:
- check type arguments in expressions
- new TypeArgumentList node to deal with diagnostic source
- ConeDiagnostic was moved to fir:cones
- ConeIntermediateDiagnostic to use in inference (?) without reporting
- detailed diagnostics on error type

Before this commit, we had effective visibility as a part of FIR status,
so it was integrated into the full pipeline. In this commit,
we introduced "effective visibility as a service" which is now used
only by exposed visibility checker. This allows us to make the thing
universal for all FIR nodes, including nodes for Java / deserialized.

Also introduce few new diagnostics:
- NONE_APPLICABLE more many inapplicable candidates
- HIDDEN for visible candidates

#KT-39080 Fixed

One of previous commit changed order for those graphs, but i didn't
  find which one

^KT-38444 In Progress

In future 'Local' effective visibility could be used
as a flag of local declaration

#KT-38432 Fixed