in ExternalFunChecker.

This allows RemoveModifierFix to provide a quickfix to remove it.

Fix after 998a65d1

It seems unnecessary to force all quickfixes to fit the `HLQuickfix`
API, especially for those existing trivial fixes that simply modifies
PSI tree. This change further loosen the API of `HLDiagnosticFixFactory`
to allow it to create arbitrary `IntentionAction` objects. This also
avoids code duplication (for example, specify the family name again in
`ReplaceCallFixFactories`).

`HLQuickfix` and the input/target paradighm can still be used where
applicable.

It looks like `project` can never be null

This information is already determined by `DIAGNOSTIC` so there is no
need to repeat it.

The factory does not need to care about what target PSI and input a
quick fix should need. We only need to ensure these two types match when
an `HLQuickfix` is created. With this constraint loosened, now one
factory can register multiple quickfixes applied on different targets
and different input. This makes it much more flexible when implementing
quickfixes.

Currently, it uses suboptimal storage for the freeze bit. This'll be revised later when we finalize stack objects handling in the new MM.

Creation of KotlinTargetsIndex takes too long,
even if Java project doesn't have any Kotlin files.
Remove function hasJsStdLib, as it takes too much time
because of recursively checking all dependencies (migrate to facets)
Also fix tests: Add Kotlin JS facet, where its needed

#KT-34351 Fixed

Finding type alias doesn't work if it's not top level because the class
ID doesn't match. There doesn't seem to be a easy way to make it work
so this commit simply makes the IDE tolerate it.

This is causing issues such as https://issuetracker.google.com/183423660.
Annotation processor options that are provided by the Android Gradle plugin
may contain references to files and file collections that are safe to
evaluate only at execution time. This change avoids eagerly creating
compiler plugin options for these options, as they are already a task input.

Test: AbstractKotlinAndroidGradleTests.testAgpNestedArgsNotEvaluatedDuringConfiguration

^KT-39715 In Progress

This will prioritize classifiers from the following sources
in the provided order

1) Classifiers from the target's modulesProvider
2) Classifiers from the traget's direct dependencies
3) Classifiers from the more common dependencies

^KT-45497

 ^KT-45497 Fixed

Before it, the wrong index lead to the validation error when repl
script definition had c-tor parameters (see test)

In a Gradle process, the user.dir property is set to the directory
where the build was started. By default, if we start a child process
via project.javaexec, Gradle sets its working directory to the
directory of the current project. But passing Gradle's value of user.dir
to that process overrides this setting.

This makes tools started in a such way sensitive to directory the build
is started from.

This patch fixes this issue for K/N-related tools started
out-of-process by the MPP Gradle plugin. But this issue is still
relevant to in-process tool execution.

In a Gradle process, the user.dir property is set to the directory
where the build was started. By default, if we start a child process
via project.javaexec, Gradle sets its working directory to the
directory of the current project. But passing Gradle's value of user.dir
to that process overrides this setting.

This makes tools started in a such way sensitive to directory the build
is started from. Thus a test using relative paths may fail if it is
started from a wrong directory.

This patch fixes this issue for Kotlin/Native tests.

^KT-45674 Fixed