updated skia version to m138-9e6b5bff162-2

Co-authored-by: Vladimir Mazunin <vladimir.mazunin@jetbrains.com>

This is part of achieving goals described in https://youtrack.jetbrains.com/issue/CMP-7674

fixes SKIKO-1035

### New:  
(related #1019)
1. Adds bindings to GrBackendTextures::MakeGL 
2. Adds bindings to SkImages::AdoptTextureFrom
3. Adds bindings to GrBackendTextures::GLTextureParametersModdified

### Changes in build scripts:
(related #742)
1. Add file paths treating if building on Windows machine
2. Use "emcc.bat" instead of "emcc" if building on Windows machine, as
described on Emscripten website

### Use-case: 
Allows skia to draw images, rendered externally on gpu.
Compose would benefit greatly, allowing to embed VideoPlayer or Browser
without any friction or need to use Swing.

New sources are in
https://github.com/JetBrains/compose-multiplatform/pull/5343

Was published in
https://teamcity.jetbrains.com/buildConfiguration/JetBrainsPublicProjects_Compose_PublishBuildHelpers/5279403
from a branch

This PR solves misleading kotlin.version parametrization which actually
was not working as expected: The actual version was always resolved from
buildSrc.

some context
https://jetbrains.slack.com/archives/C0288G57R/p1749820141169649

[CMP-8343](https://youtrack.jetbrains.com/issue/CMP-8343) Support
`TransformShader` in skiko implementation

Resolving TODO from
https://github.com/JetBrains/compose-multiplatform-core/pull/2171

A followup for https://github.com/JetBrains/skiko/pull/1051

This PR adds support for the linuxArm64 target. It can be cross compiled
from a Linux x64 host.

The `multistrap` package is used for downloading some required arm64
dependencies.

# Testing

GitHub run: https://github.com/Thomas-Vos/skiko/actions/runs/15261348943

Also using it in a compose app.

Needed to add `ARG DEBIAN_FRONTEND=noninteractive` so installation does
not get stuck, copied this from another Dockerfile.
Also `binutils-2.26` was missing so replaced it with `binutils`, this is
in line with the other docker files, but I am unsure if this could break
anything.

On my PC the image build is successful (using `build.sh` script). The
`run.sh` script is also successful after adapting its paths to my local
setup. Unsure about publishing.

Update linux-amd64/Dockerfile with dependencies needed for cross compiling linuxArm64 target (#1061)

https://github.com/JetBrains/skiko/pull/1051#discussion_r2107305732

This fixed
[issue](https://youtrack.jetbrains.com/issue/CMP-7405/Invalid-imports-in-skiko-to-skia-API)
for non-JVM targets.

Some of this fixes overlapped by
[this](https://github.com/JetBrains/skiko/pull/1050) and
[this](https://github.com/JetBrains/skiko/pull/1049) MR's. We could drop
then here or close that MR's at the discretion of the reviewer.

Continuation of https://github.com/JetBrains/skiko/pull/1055

This runs only in master

This PR contain:
1. Using shared metal textures with this JBR API -
[SharedTextures](https://github.com/JetBrains/JetBrainsRuntimeApi/blob/main/src/com/jetbrains/SharedTextures.java).
See `AcceleratedSwingPainter`.

2. Not ultimate, but visible improvement of the not accelerated painting
for Windows(~%25), and MacOS(~20%). Unfortunately, didn't manage to see
a positive change on Linux with XRender pipeline(about the same,
probably few percents down). With opengl pipeline it also got ~20%
faster. But currently our pipeline on linux is XRender
I got rid of make one extra copy of the raster image. See
`SoftwareSwingPainter`

`com.jetbrains:jbr-api` size is about 44kb

Benchmarks:
`Redraw` - time to prepare the offscreen image including sync, but not
including fetching texture to the CPU RAM
`Paint` - time to get the image from GPU(if needed) and draw onto
`Graphics2D`
`Total` - total time to deliver the frame

```
MetalSwingRedrawer:
Image size: 3200x2344
Test: ClocksAwt
MacBook Pro M1 Max
java2d pipeline = Metal
               Current   SoftwareSwingPainter   AcceleratedSwingPainter
FPS              66             80                      141
Redraw(ms)      7.13           7.13                     6.92
Paint(ms)       7.65           6.07                     0.006
Total(ms)      14.78          12.16                     6.92


Direct3DSwingRedrawer
Image size: 3176x2284
Dell Prescision 5570, i9-12900H + GPU Nvidia
Test: ClocksAwt
java2d pipeline = GDI
               Current   SoftwareSwingPainter
FPS              32             41
Redraw(ms)     12.58          11.57
Paint(ms)      17.43          11.54
Total(ms)      29.93          23.11


LinuxOpenGLSwingRedrawer
Image size: 3192x2230
Dell Prescision 5570, i9-12900H + GPU Nvidia
Test: ClocksAwt
java2d pipeline = XRender
               Current   SoftwareSwingPainter
FPS              24             23
Redraw(ms)     20.07          19.64
Paint(ms)      19.69          22.73
Total(ms)      39.77          42.39
```

---------
Co-authored-by: Igor Demin <igordmn@users.noreply.github.com>

The current runners fail with:

This is a scheduled Ubuntu 20.04 retirement. Ubuntu 20.04 LTS runner
will be removed on 2025-04-15. For more details,
see https://github.com/actions/runner-images/issues/11101

GitHub Actions has encountered an internal error when running your job.

feat(jvm): add GLAssembledInterface.createFromNativePointers and DirectContext.makeGLWithInterface (#1048)

Needed to enable OpenGL on Wayland (via EGL)

"AndroidRelease" should be used instead of "Android" since using the
android plugin introduces release/debug variants.

Note: `./gradlew publish -Pskiko.android.enabled=true` would still fail
with the following, but this task is as I understand not used on CI and
"build repo" seem to be a local thing.
```
> Task :publishAndroidReleasePublicationToBuildRepoRepository FAILED

FAILURE: Build failed with an exception.

* What went wrong:
A problem was found with the configuration of task ':publishAndroidReleasePublicationToBuildRepoRepository' (type 'PublishToMavenRepository').
  - Gradle detected a problem with the following location: '/Users/cdelabou/workspace/misc/skiko/skiko/build/libs/skiko-0.0.0-SNAPSHOT-javadoc.jar.asc'.
    
    Reason: Task ':publishAndroidReleasePublicationToBuildRepoRepository' uses this output of task ':signKotlinMultiplatformPublication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
```

We have a situation on a Linux where a significant portion of time spent
in EDT is spent inside a `glFinish()` call.

OS: Linux bazhenov 6.11.0-19-generic #19~24.04.1-Ubuntu SMP
PREEMPT_DYNAMIC Mon Feb 17 11:51:52 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Distribution: Ubuntu 24.04
GPU: Intel Corporation AlderLake-S GT1 [8086:4680] (rev 0c) (Intel UHD
Graphics 770)
Driver: i915


![screenshot_from_2025-03-24_14-04-41](https://github.com/user-attachments/assets/a4ed84e1-d299-418e-912c-3f32b15bfaaa)

According to the
[documentation](https://registry.khronos.org/OpenGL-Refpages/gl4/html/glFinish.xhtml):

> glFinish does not return until the effects of all previously called GL
commands are complete. Such effects include all changes to GL state, all
changes to connection state, and all changes to the frame buffer
contents.

It effectively means that there is no overlap in work being done on the
CPU and GPU; we only start to prepare a new frame when we finish
rendering the previous one. It makes sense in the context of direct
draw, but AFAIK, Skiko has a swap chain of frame buffers (I assume 2?),
so `glFlush()` should be enough. Probably, we can get away without
`glFinish()`/`glFlush()` at all, because `glSwapBuffers()`, according to
the documentation, is doing `glFlush()`, but I'm not an expert.

Using `SkiaAwtSample`, I can confirm that performance is improved
significantly (in both cases first 3 FPS samples are skipped).

Before change

```
[1039125906] FPS 36 (29-63)
[1039127906] FPS 46 (29-62)
[1039129906] FPS 43 (29-64)
[1039131922] FPS 39 (29-64)
[1039133923] FPS 42 (29-65)
[1039135940] FPS 52 (29-63)
[1039137957] FPS 36 (29-62)
[1039139974] FPS 53 (29-66)
[1039142008] FPS 34 (29-63)
[1039144024] FPS 47 (30-66)
```

After change

```
[1038654097] FPS 60 (46-67)
[1038656097] FPS 60 (57-65)
[1038658114] FPS 60 (47-68)
[1038660114] FPS 60 (41-67)
[1038662114] FPS 60 (51-67)
[1038664115] FPS 60 (47-67)
[1038666115] FPS 60 (51-67)
[1038668115] FPS 60 (51-67)
[1038670127] FPS 60 (42-67)
[1038672132] FPS 60 (48-67)
```

Follows up MR #1043 that got reverted, new changes also include
corrected signature configuration

https://jetbrains.slack.com/archives/C02DDNREC77/p1744211587478839?thread_ts=1744180296.015109&cid=C02DDNREC77

- now 0.0.1-SNAPSHOT is built
- it can't be used, as it is built from any branch, not only from master

Reverts JetBrains/skiko#1043

```
./gradlew publishKotlinMultiplatformPublicationToComposeRepoRepository
```
Fails on CI

This also fixes SKIKO-934 by making the dependency between
`merge*JniLibFolders` and `unzip*` tasks explicit (the patch actually
adds too much dependencies but this should be limited to android tasks).
After this patch the android sample works from my configuration (might
be worth checking if other issues are still relevant?).

Few things to consider for review:
- I've changed versions of Gradle / AGP / Kotlin until I got something
working on both samples and library side.
- If `ANDROID_SDK_ROOT` environment variable was specified on a CI
before, it should now be `ANDROID_HOME` to work with android gradle
plugin (internal utilities will work with both).
- I've introduce some lazyness in configurations (`matching { ... }`),
as android plugin and previous code would race (android seems to declare
it's configurations quite late). If there's a better way to express it,
please let me know!

renderApi can change if there was a fallback (DIRECT3D -> OpenGL ->
Software). We need to always call it in the frame.

Noticed it during testing.

emscripten 3.1.50 supports mimalloc -
https://github.com/emscripten-core/emscripten/blob/main/ChangeLog.md#3150---112923

We want to try it.

This change will be used in Compose Multiplatform to fix
https://youtrack.jetbrains.com/issue/CMP-6589/wasm-can-not-render-tab-symbol

The difference can be seen here:
**Good**: https://fiddle.skia.org/c/24fb7ebc20eec08077d84b9fe37ceb4f -
`paraStyle.setReplaceTabCharacters(true);`
**Bad**: https://fiddle.skia.org/c/fbcb4a52786d63ed42a85d05d5472164 -
`paraStyle.setReplaceTabCharacters(false);`

Creating transparent views/renderers shouldn't disable window shadows

Context: [CMP-7752](https://youtrack.jetbrains.com/issue/CMP-7752)
Interop blending should not disable window shadows on macOS

This is needed to detect emojis in Compose Multiplatform.

Also, it looks like the native implementations of
`String.intCodePoints()` were broken. I fixed them by copying the
relevant code from Compose.

see https://youtrack.jetbrains.com/issue/CMP-7630

It's for internal usage only (for example in benchmarks).

- skikoWasmJar will include a new file - skikod8.mjs
- The new file skikod8.mjs won't be used by any actual apps (Compose
apps). The apps won't try to download it or use it.
- This file can be used by manually replace skiko.mjs usages (we'll do
it using a gradle task in benchmarks project)

___
This step is required for https://youtrack.jetbrains.com/issue/CMP-6942

My app is used a lot in the background, and I noticed high CPU usage in
the native macOS version. With this PR, CPU usage is reduced when window
is invisible by disabling drawing. This was already implemented for the
JVM, and that behaviour is now copied to native macOS. So the code is
similar to JVM parts in:
-
https://github.com/JetBrains/skiko/blob/master/skiko/src/awtMain/kotlin/org/jetbrains/skiko/redrawer/MetalRedrawer.kt
-
https://github.com/JetBrains/skiko/blob/master/skiko/src/awtMain/objectiveC/macos/MetalRedrawer.mm

The draw function is now suspend, which required moving some other
functions around. I tried to keep the implementation similar to the JVM
version.

# Testing
Tested using `./gradlew runNative` in `samples/SkiaMultiplatformSample`.
Now the CPU usage is reduced a lot when moving another (non transparent)
app over the window.

# Old behaviour


https://github.com/user-attachments/assets/60ad3398-3f44-4e2f-aca7-44a4607d0840

# New behaviour with 300ms timeout
See reduction in CPU usage when window is invisible


https://github.com/user-attachments/assets/106efdeb-0044-4411-9b26-5a6b8886ff04


# New behaviour without 300ms timeout



https://github.com/user-attachments/assets/b986548b-d7ab-497b-9ddb-5b46ca016f83