Migrate Google's devsite-plugin to analysis-kotlin-api

[IgnatBeresnev]

Dokka 1.9.0 introduces some breaking changes that affect the plugin that builds Android's API reference docs.

This plugin uses significantly more compiler internals than any other Dokka plugin, so we need to provide stable alternatives for the now-missing API, and help with migration where possible.

---

Definition of done: dokka-devsite-plugin has migrated to analysis-kotlin-api, and no regression was noticed.

[IgnatBeresnev]

API-wise, what needs to be done from Dokka's side:

• ExternalDocumentablesProvider - should be made public and stable. Used for resolving supertypes.
• org.intellij.markdown.MarkdownElementTypes.MARKDOWN_FILE - needs a public and stable substitution. The use case is the same as in Dokka: used as the default name for a doc tag, so it needs to be reflected in the name.
• SampleTransformer - the interface SampleProvider introduced in #3102 will cover the use cases. Should be made public and stable, and we should add more details to the documentation so that the body-processing guarantees (such as whitespace trimming) are not lost.

Not planned:

• KotlinToJavaService - not actually needed, can stay internal.
• Transitive utility functions (everything from addToStdlib, com.jetbrains.rd.util and other packages) - no way for us to replace them.

[IgnatBeresnev]

Regression-wise, there are some problems with inheritance, but it's unclear where it's coming from: might be the refactoring, might be the compiler, might be some custom logic in devsite plugin.

Examples:

• Enums no longer extending the kotlin.Enum class
• Classes that extend List or CoroutineContext have no inheritance information anymore.

[IgnatBeresnev]

New request: there should be some API that helps determine the source/origin language of a Documentable, to be able to say whether it's coming from Kotlin or Java code/analysis. Previously, the following check was possible:

(documentable as? WithSources).sources.entries.singleOrNull.value is PsiDocumentableSource

But the PsiDocumentableSource class is no longer available, it's now internal.

---

We have an internal alternative in the form of DocumentableSourceLanguageParser extension, so it might be enough to "stabilize" it by providing a clear contract and making it public.

Notes on the implementation:

• Having an enum (like the existing DocumentableLanguage) might be undesirable because there's no room for extension in 3rd party plugins or analyses. Not sure if it's a capability worth providing though.
• This capability could be moved from an external interface/extension to be inside the WithSources interface, but WithSources is a bit misleading as it can exist even for declarations that do not have sources.

[IgnatBeresnev]

Blocked by #3573