in ExternalFunChecker.

This allows RemoveModifierFix to provide a quickfix to remove it.

#KT-45339 Fixed

 #KTIJ-5663 Fixed

ReplaceCallFix.

AbstractHighLevelQuickFixTest.

 Now we can generate proper defaults and there is no need in additional
 checks about unimplemented methods

 #KT-41130 Fixed

 This is needed for the next commit to check jvm-default options

 #KT-41130 In Progress

From now on sealed declarations get resolved with the help of
FirIdeSealedHierarchyProcessor. This change entails correct IDE side
check for sealed when exhaustiveness.

There are only simple checks for `external` and `const` for now. The
rest of the checks (see ModifiersChecker in FE1.0) will be added later.

FIR: render value parameter/lambda/accessor resolve phase if RenderMode.renderDeclarationResolvePhase is enabled

^KT-45145 Fixed

For a vararg parameter type, there corresponding FIR element has a fake
source of kind ArrayTypeFromVarargParameter. As a result,
`getOrBuildFir` returns the whole `FirValueParameter` for the parameter
type reference. Therefore, we need some special handling for this case
in order to resolve the proper `KtSymbol`.

The main purpose is to show that old frontend and FIR work differently
in the case of the conflicts of local and top level classes/objects

See the tests that marked with // IGNORE_FIR

Corresponding ticket is ^KT-45192

Note that LazyClassMemberScope actually has a separate field for
KotlinTypeRefiner, and it might be actually different from the one in
c.kotlinTypeChecker.

The one in c.kotlinTypeChecker is the refiner of *owner* module, i.e. a
module in which the class has been declared. If we have a class Foo :
Expect in common, then the refiner will be from common, and thus it
won't be able to refine supertypes to their platform-dependent values.

The one passed in constructor is actual refiner of dependant-module.
Say, if we're looking at Foo from the point of view of jvmMain, then
we'll create a (view-dependent) LCMS for that, and it will contain
refiner for jvmMain.

It is important to use proper refiner, otherwise the idea of having
"module-dependent view" breaks, and we might suddenly mismatch some
overrides with expect-classes in their signatures.

^KT-44898 Fixed

The current behaviour is undesired (ABSTRACT_MEMEBER_NOT_IMPLEMENTED
reported on class Concrete), will be fixed in the next commit

#KT-38155 Fixed

  1. NON_ABSTRACT_FUNCTION_WITH_NO_BODY
  2. ABSTRACT_PROPERTY_IN_NON_ABSTRACT_CLASS
  3. ABSTRACT_FUNCTION_IN_NON_ABSTRACT_CLASS

Relates to #KT-37702
#KTIJ-1246 Fixed

Original commit: bd222a5255c2fd6f4abfce3115f81733ef9a39f3