Use JS IR backend and generate TypeScript sources

[Whathecode]

This is a proof-of-concept to show how generated TypeScript (TS) sources for this project can be augmented with manually written TS declarations to:

• export types from external libraries which aren't exported (no @JsExport applied)
• export types which can't be exported yet (@JsExport can't be applied due to current Kotlin JS limitations)

This PR replaces a previous attempt at doing the same on Kotlin 1.6.10, with an approach which works for Kotlin 1.8.0.

This is mostly a hack, but shows that this is feasible. In short:

• The publish-npm-packages project depends on the projects which need to be exported and includes JsExport on classes which ensure that APIs which need to be made publicly available aren't optimized out. The JS output of this project can also be used to look up mangled method names.
• copyTestJsSources in build.gradle copies the build output of publish-npm-packages into node modules (no package.json for publication created yet)
• Copied files are modified to:
  • Refer to node modules instead of relative file paths.
  • Types which are used across modules but aren't JS exported are exported through $_$ using mangled names. Include additional exports of named internal types needed for TS augmentations. These are specified in the publish-npm-packages/src/forced-exports folder in a separate file per module.
• typescript-declarations/@types contains TS declarations for the named types forced to be exported in forced-exports.
• typescript-declarations/src contains facades exporting the types used for internal communication by augmenting them with clean interfaces in the expected namespaces and adding facade methods with clean names which map to the mangled ones.

The unit tests which were implemented for the JS Legacy backend now pass on the JS IR backend with the augmented non-mangled TS declarations. Unmangled facades with sufficient functionality to use the CARP APIs have been added for the Kotlin standard library, kotlinx datetime, and kotlinx serialization. Regex could be exported similarly as well, but there is no real use since this is not exposed in relevant APIs for web clients and only used for internal logic.

With these APIs made available in the expected namespaces, the next step is to:

• apply another post-compilation step which replaces non-exportable types, which are represented as any followed by their Kotlin type in a comment in TypeScript, with the actual type for all augmented types made available through declaration merging.

@JsExport, where possible, has been applied to CARP:

• common
• studies
• protocols
• deployment
• data

Serializers haven't been exported since they are already available through the companion object. The following types @JsExport couldn't be applied to due to compiler warnings.

CARP common:

• ApplicationService (nice to have, but not needed)
• SamplingConfigurationBuilder (no real need)
• SamplingConfigurationMapBuilder (no real need)
• ApplicationServiceEventBus (full file, no real need)
• EventBus (full file, no real need)
• RangeExtensions (extension functions can be exported, but no need and increases JS size)

For all services in deployments/studies/protocols/data subsystems, due to Kotlin JS compiler bug:

• XYZService (nice to have, but not needed)
• XYZServiceHost (not needed)

Augmentations to work around non-exportable types have been applied to types in CARP:

• common
• studies
• protocols
• deployment
• data

[Whathecode]

Just managed to get a big blocker out of the way. Application service request objects are now exported to JS!

[xelahalo]

The generated sources look sweet 🤙

Now the only thing that would be nice is a way for us to access the sources through NPM. Though I think I could easily do that for you, I've done something similar with GitHub packages.