Fix "ComposePanel doesn't use hardware acceleration with RenderSettings.SwingGraphics on Linux" (#1103)

Fixes https://youtrack.jetbrains.com/issue/CMP-8936

`glXChooseFBConfig` fails to find a config with `GLX_DOUBLEBUFFER,
False` on my machine, it only has double buffered configs. But
double/single buffering doesn't matter as we use pixel buffers.

Also choose a correct config that is required by
https://registry.khronos.org/OpenGL-Refpages/gl2.1/xhtml/glXCreatePbuffer.xml:
```
BadMatch is generated if config does not support rendering to pixel buffers (e.g., GLX_DRAWABLE_TYPE does not contain GLX_PBUFFER_BIT)
```

## Testing
- manually, in the clocks example
- the modified test failed before the fix, now it doesn't fail

## Release Notes (Skiko)
Fix "SkiaSwingLayer doesn't use hardware acceleration on Linux"

## Release Notes (Compose)
### Fixes - Desktop 
Fix "ComposePanel doesn't use hardware acceleration with
RenderSettings.SwingGraphics on Linux"

Fixes:
[CMP-8916](https://youtrack.jetbrains.com/issue/CMP-8916/Provide-a-way-to-configure-Skias-DirectContext-GPU-Resource-Cache-size)

The cache can be limited on Desktop platforms by specifying
`-Dskiko.gpu.resourceCacheLimit` VM property (accepts numbers optionally
suffixed with "K", "M" or "G").

Generate release notes like in
https://github.com/JetBrains/skiko/releases/tag/v0.9.25 automatically

It fixes
```
:setupMultistrapLinuxArm64
  E: Can't find a source to download version '2020.02.11.4' of 'ubuntu-keyring:amd64'
```
failure on CI (#1096 regression).

Usually `/var/lib/apt/lists` is recommended to be removed from final
docker images. But in our case, `multistrap` tool requires downloading
some dependencies during the build.
It's the issue only on `linux-amd64`, for others linux images this
removal is correct.

Publishing CI fails after Gradle update because of it

Changes:
- Moved Windows docker image from compose repo
- Update JDK to 21 in all images
- Cleanup unused scripts/CI stages/etc

This PR updates SkikoJsSample (which is renamed to SkikoWebSample) in
following aspects:

- By default sample built against release version so that user can check
the sample without local build at all
- When build against local skiko, `skiko.version` parameter is ignored
- Sample code commonized and prepared for future introduction of common
web source sets in Kotlin 2.2.20

Fixes [SKIKO-1039](https://youtrack.jetbrains.com/issue/SKIKO-1039)
Update Skiko project to K2

- Update Kotlin to 2.0.10
- Fix `InteropPointer` declaration
- Fix warnings

Fixes [SKIKO-761](https://youtrack.jetbrains.com/issue/SKIKO-761)
SkikoAndroidSample crashes with skiko v0.7.68

Testing: run `SkikoAndroidSample`

Also:

- Update JDK in GitHub Actions to 21
- AGP in SkiaAndroidSample to 8.9.0
- Kotlin in SkiaAwtSample to 1.9.21
- macosx-version-min=10.15 (align to skia, there was a warning)
- Various deprecation warnings in build scripts

Following changes introduced in this PR:
* jsWasmMain and jsWasmTest sourcesets renamed to webMain and webTest
(it causes less confusion, regarding the fact that we already have
wasmJsMain, apart from that, this would be a standard name for this
sourceset in webMain)
* remove redunant resource processing (there's yet room for improvement
though)
   * Simplify wasm task introduction
* Remove flag for building js separately from wasm (this flag was a lie
- we can not have separate js target)

Update instructions for VS 2022.

It is now required for development. Tested it locally

This change adds ANGLE renderer support to Skiko.

[ANGLE project](https://chromium.googlesource.com/angle/angle)
translates OpenGL ES API calls to the native platform's graphics API.
This is mostly useful on Windows where ANGLE provides the Direct3D 11
backend.

Right now, there is a gap in Skiko's graphics support. On Windows ARM,
Skia doesn't support OpenGL yet. At the same time, some GPUs, like
Parallels or VMware virtual GPUs, don't support DirectX 12. This means
Skiko falls back to the slow software rendering on those GPUs. ANGLE
solves this problem by providing an easy-to-use DirectX 11 backend.

In addition, ANGLE is used by Chromium-based browsers and apps, so we
expect it to be more stable than Skia's DirectX backend.

---------
Co-authored-by: Igor Demin <igor.demin@jetbrains.com>

Fixes [CMP-8701](https://youtrack.jetbrains.com/issue/CMP-8701)

Addition to https://github.com/JetBrains/skia/pull/11

It contains
- https://github.com/JetBrains/skia/pull/10
- https://github.com/JetBrains/skia/pull/11
- https://github.com/JetBrains/skia/pull/12
- https://github.com/JetBrains/skia/pull/13

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>