See
[CMP-9080](https://youtrack.jetbrains.com/issue/CMP-9080/Native-Crash-in-Skiko-on-desktop#focus=Comments-27-13023060.0-0)
for details

Reverts JetBrains/skiko#1125

Fails on CI

Regression after https://github.com/JetBrains/skiko/pull/1119 was added
on CI

```
org.gradle.internal.execution.WorkValidationException: A problem was found with the configuration of task ':signKotlinMultiplatformPublication' (type 'Sign').
  - Gradle detected a problem with the following location: '/mnt/agent/work/381d14fe560aa354/skiko/build/libs/skiko-0.9.33-javadoc.jar.asc'.

    Reason: Task ':publishAwtRuntimeElementsPublicationToComposeRepoRepository' 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.

    Possible solutions:
      1. Declare task ':signKotlinMultiplatformPublication' as an input of ':publishAwtRuntimeElementsPublicationToComposeRepoRepository'.
      2. Declare an explicit dependency on ':signKotlinMultiplatformPublication' from ':publishAwtRuntimeElementsPublicationToComposeRepoRepository' using Task#dependsOn.
      3. Declare an explicit dependency on ':signKotlinMultiplatformPublication' from ':publishAwtRuntimeElementsPublicationToComposeRepoRepository' using Task#mustRunAfter.
```

The fix is blind as we can only test it in master

This publication creates one variant for each native platform. 
It allows depending (and exposing) a single dependency, which can later
be resolved to platform-specific artifacts.

<details>
<summary>skiko-awt-runtime.module</summary>

```json
{
  "formatVersion": "1.1",
  "component": {
    "group": "org.jetbrains.skiko",
    "module": "skiko-awt-runtime",
    "version": "1.0-SNAPSHOT",
    "attributes": {
      "org.gradle.status": "integration"
    }
  },
  "createdBy": {
    "gradle": {
      "version": "8.13"
    }
  },
  "variants": [
    {
      "name": "jvmRuntimeElements-macos-x64",
      "attributes": {
        "org.gradle.category": "library",
        "org.gradle.dependency.bundling": "external",
        "org.gradle.jvm.environment": "standard-jvm",
        "org.gradle.libraryelements": "jar",
        "org.gradle.native.architecture": "x86-64",
        "org.gradle.native.operatingSystem": "macos",
        "org.gradle.usage": "java-runtime",
        "org.jetbrains.kotlin.platform.type": "jvm"
      },
      "dependencies": [
        {
          "group": "org.jetbrains.skiko",
          "module": "skiko-awt-runtime-macos-x64",
          "version": {
            "requires": "1.0-SNAPSHOT"
          }
        }
      ]
    },
    {
      "name": "jvmRuntimeElements-macos-arm64",
      "attributes": {
        "org.gradle.category": "library",
        "org.gradle.dependency.bundling": "external",
        "org.gradle.jvm.environment": "standard-jvm",
        "org.gradle.libraryelements": "jar",
        "org.gradle.native.architecture": "aarch64",
        "org.gradle.native.operatingSystem": "macos",
        "org.gradle.usage": "java-runtime",
        "org.jetbrains.kotlin.platform.type": "jvm"
      },
      "dependencies": [
        {
          "group": "org.jetbrains.skiko",
          "module": "skiko-awt-runtime-macos-arm64",
          "version": {
            "requires": "1.0-SNAPSHOT"
          }
        }
      ]
    }
  ]
}
```

</details>


<details>
<summary>skiko-awt-runtime.pom</summary>

```xml
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
  <!-- This module was also published with a richer model, Gradle metadata,  -->
  <!-- which should be used instead. Do not delete the following line which  -->
  <!-- is to indicate to Gradle or any Gradle module metadata file consumer  -->
  <!-- that they should prefer consuming it instead. -->
  <!-- do_not_remove: published-with-gradle-metadata -->
  <modelVersion>4.0.0</modelVersion>
  <groupId>org.jetbrains.skiko</groupId>
  <artifactId>skiko-awt-runtime</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>pom</packaging>
  <name>Skiko JVM Runtime</name>
  <description>Kotlin Skia bindings</description>
  <url>https://www.github.com/JetBrains/skiko</url>
  <licenses>
    <license>
      <name>The Apache License, Version 2.0</name>
      <url>http://www.apache.org/licenses/LICENSE-2.0.txt</url>
    </license>
  </licenses>
  <developers>
    <developer>
      <name>Compose Multiplatform Team</name>
      <organization>JetBrains</organization>
      <organizationUrl>https://www.jetbrains.com</organizationUrl>
    </developer>
  </developers>
  <scm>
    <connection>scm:git:https://www.github.com/JetBrains/skiko.git</connection>
    <developerConnection>scm:git:https://www.github.com/JetBrains/skiko.git</developerConnection>
    <url>https://www.github.com/JetBrains/skiko</url>
  </scm>
</project>
```

</details>



Simple example usage:
```kotlin
kotlin {
    target.attributes {
        attribute(ARCHITECTURE_ATTRIBUTE, objects.named(DefaultNativePlatform.getCurrentArchitecture().name))
        attribute(OPERATING_SYSTEM_ATTRIBUTE, objects.named(DefaultNativePlatform.getCurrentOperatingSystem().toFamilyName()))
    }
}

dependencies {
    implementation("org.jetbrains.skiko:skiko-awt:1.0-SNAPSHOT")
    implementation("org.jetbrains.skiko:skiko-awt-runtime:1.0-SNAPSHOT")
}
```

## Motivation
This allows 'intermediate' libraries to express that this dependency
exists (in a single publication) and push down the artifact selection to
consumers. This is an advanced feature and can be leveraged by more
complex builds.

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

It's due to
> The macOS-13 based runner images are being deprecated, consider
switching to macOS-15 (macos-15-intel) or macOS 15 arm64 (macos-latest)
instead.

… 'skiko.awt.enabled' feature flag

Skia supports all DX12 feature levels, see here for example:
https://source.chromium.org/chromium/chromium/src/+/main:third_party/skia/tools/ganesh/d3d/D3DTestUtils.cpp;l=60;drc=cbb0388767d2b8a5a5c1f5484a68fb0ff201561b

It appears however that some GPUs (like Intel(R) HD Graphics 4600) don't
work with Skia's DirectX backend at all. Those adapters should be marked
as unsupported in Skiko instead.

The reason for this change is that the current choice of feature levels
disables support for "good" FL11.1-compatible adapters, for example, the
Parallels Virtual GPU.

Feature level 11.1 is chosen as a safe bet for now since it's
effectively the same as 12.0, with some baseline features of 12.0 being
optional here.

The original issue: #601 
The original PR: #603

Revert "Migrate Dockerfiles to use Amazon Linux 2 from Ubuntu 20.04 for both amd64 and arm64 platforms" (#1121)

Reverts JetBrains/skiko#1120

Due to publish issues on linux arm64:
```
Execution failed for task ':setupMultistrapLinuxArm64'. org.gradle.process.internal.ExecException: A problem occurred starting process 'command 'multistrap''
```

Migrate Dockerfiles to use Amazon Linux 2 from Ubuntu 20.04 for both amd64 and arm64 platforms (#1120)

As of November Google requires 16kb page sizes for native libraries.

https://developer.android.com/guide/practices/page-sizes

Updated the ndk version in the gradle and docker files

Tested this with the sample app and also with a more complex project.

Fixes [SKIKO-1064](https://youtrack.jetbrains.com/issue/SKIKO-1064)

Reverts JetBrains/skiko#1082

Sign task failed on CI
(`publishSkikoJvmRuntimeWindowsX64PublicationToComposeRepoRepository`):
```

  Some problems were found with the configuration of task ':signSkikoJvmRuntimeWindowsX64Publication' (type 'Sign').
16:29:09     - Gradle detected a problem with the following location: 'C:\buildagent\work\381d14fe560aa354\skiko\build\libs\skiko-0.9.28+debug-javadoc.jar.asc'.

  org.gradle.internal.execution.WorkValidationException: Some problems were found with the configuration of task ':signSkikoJvmRuntimeWindowsX64Publication' (type 'Sign').
    - Gradle detected a problem with the following location: 'C:\buildagent\work\381d14fe560aa354\skiko\build\libs\skiko-0.9.28+debug-javadoc.jar.asc'.
      
      Reason: Task ':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository' uses this output of task ':signSkikoJvmRuntimeWindowsX64Publication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
      
      Possible solutions:
        1. Declare task ':signSkikoJvmRuntimeWindowsX64Publication' as an input of ':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository'.
        2. Declare an explicit dependency on ':signSkikoJvmRuntimeWindowsX64Publication' from ':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository' using Task#dependsOn.
        3. Declare an explicit dependency on ':signSkikoJvmRuntimeWindowsX64Publication' from ':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository' using Task#mustRunAfter.
      
      For more information, please refer to https://docs.gradle.org/8.14.3/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.
    - Gradle detected a problem with the following location: 'C:\buildagent\work\381d14fe560aa354\skiko\build\libs\skiko-0.9.28+debug-sources.jar.asc'.
      
      Reason: Task ':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository' uses this output of task ':signSkikoJvmRuntimeWindowsX64Publication' without declaring an explicit or implicit dependency. This can lead to incorrect results being produced, depending on what order the tasks are executed.
      
      Possible solutions:
        1. Declare task ':signSkikoJvmRuntimeWindowsX64Publication' as an input of ':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository'.
        2. Declare an explicit dependency on ':signSkikoJvmRuntimeWindowsX64Publication' from ':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository' using Task#dependsOn.
        3. Declare an explicit dependency on ':signSkikoJvmRuntimeWindowsX64Publication' from ':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository' using Task#mustRunAfter.
      
      For more information, please refer to https://docs.gradle.org/8.14.3/userguide/validation_problems.html#implicit_dependency in the Gradle documentation.
```

An addition to [the feature
PR](https://github.com/JetBrains/skiko/pull/1017) that allows including
ANGLE the same way as Skiko native libraries included:
- unpack it from an additional jar
`org.jetbrains.skiko:skiko-awt-runtime-angle-$target:$version`
- find them in `skiko.library.path` directoty (a system property)
- find them in `java.home`

It reuses the same logic that is used to load `Skiko.dll`.

Currently only Windows supported, the same way as in the original PR.

No CI changes needed, as building of this jar is added as a dependency
for
`publishSkikoJvmRuntimeWindowsX64PublicationToComposeRepoRepository`/`publishSkikoJvmRuntimeWindowsArm64PublicationToComposeRepoRepository`

## Testing

Manually with `skiko.rendering.angle.enabled` true/false on
SkikoAwtSample.

## Release Notes (Skiko)
### Features - Desktop
A new experimental renderer is introduced for Windows. It uses [the
ANGLE library](https://github.com/google/angle) which has proven to be
stable because it is used inside Chromium, compared to the `DIRECT3D`
renderer that has issues on a few machines. Note that `ANGLE` still uses
`DIRECT3D` API under the hood.

1. Add this to the code to enable it:
```
System.setProperty("skiko.rendering.angle.enabled", "true")
```

2. Add the ANGLE library into the dependencies:
  - If you use Gradle:
  ```
  if (System.getProperty("os.name").startsWith("Win")) {

implementation("org.jetbrains.skiko:skiko-awt-runtime-angle-$target:$version")
  }
  ```
- If you set `skiko.library.path`. Extract `libEGL.dll`, `libGLESv2.dll`
from https://github.com/JetBrains/angle-pack/releases into this
directory.

## Release Notes (Compose)
### Features - Desktop
N/A

Until we specify how to match Skiko and Compose versions, or include it
in Compose, it is a Skiko-only experimental feature. Some projects can
include Skiko directly, it should work, but not supported as a Compose
feature.

Restoring correct behaviour of caches after #1108

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

Fixed 
- Unresolved reference 'layer' in MacosClocks constructor
- Added startup trigger `skiaLayer.needRedraw()` in main()

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