Fixes [SKIKO-1101](https://youtrack.jetbrains.com/issue/SKIKO-1101)
Prevent possible version mismatch between skiko Kotlin and JNI parts

Fixes CMP-1460

Requires skia-pack version update before merging:
https://github.com/JetBrains/skia-pack/pull/68

Required for my linuxArm64 device which only support EGL.

https://youtrack.jetbrains.com/issue/SKIKO-918

This is part 2 of [this
pr](https://github.com/JetBrains/skiko/pull/1137)

**What has changed?**
1. Added more extension functions that prevent intermediate object
allocations from a lot of the Skiko api surface
2. Migrated EnumClass.values() to entries in a lot of classes (maybe
some have been missed)

**Next**
Try (important keyword here :), cause if not wrong there are Skia and
Compose diffs on how they're treated) doing less copies of Matrix

## Release Notes
Added API that can accept primitive values instead of `Rect`, `RRect`, `Offset` to avoid additional object allocation

Fixes [SKIKO-1081](https://youtrack.jetbrains.com/issue/SKIKO-1081) Make
docker images for building skiko publicly available

The Skiko project previously used a private Docker registry
(`registry.jetbrains.team/p/ui/skiko-docker`) for build containers,
which required secrets for authentication. This prevented CI
verification from fork PRs even after manual approval.

The change migrates to GitHub Container Registry (GHCR), making
containers publicly accessible and enabling CI to run on fork PRs.

Containers built:
https://github.com/orgs/JetBrains/packages?repo_name=skiko

Triggers:
- Push to master: Automatically builds and publishes all Docker images
- Pull requests: Builds images in dry-run mode (no publishing) for
verification
- Manual workflow dispatch: Option to publish or just build
- File changes: Triggers on changes to `skiko/docker/**` or the workflow
itself

This PR fixes https://youtrack.jetbrains.com/issue/SKIKO-996

The PixelRef bindings have two mistakes in them:

1. `rowBytes` is defined as a `NativePointer`, whereas it is actually an
integer with the number of bytes per row. This is the same as
`Bitmap::rowBytes`.
2. It is missing the `pixels` property that actually returns a pointer
to the pixel data.

See: https://api.skia.org/classSkPixelRef.html

On January 12th `18.4` was removed from GitHub Actions runners
See https://github.com/actions/runner-images/issues/13392

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

Fixes
https://youtrack.jetbrains.com/projects/SKIKO/issues/SKIKO-1040/Web-targets-not-optimal-use-of-FinalizationRegistry-API

It improves some microbenhcmarks according to
https://github.com/WebKit/JetStream/pull/84#discussion_r2254866128

Added some functions to Skia canvas to be able to avoid creating
intermediate objects (SkRect, SkRRect, etc) on some hot paths.
See [this
conversation](https://github.com/JetBrains/compose-multiplatform-core/pull/2543#discussion_r2483008621)
for the context of the PR.
This is the first step to allow for Compose Ui SkiaBackedCanvas to avoid
unnecessary intermediate allocations:
1.
https://github.com/JetBrains/compose-multiplatform-core/blob/47af63a3986292608982f421bb345eb0a2032a98/compose/ui/ui-graphics/src/skikoMain/kotlin/androidx/compose/ui/graphics/SkiaBackedCanvas.skiko.kt#L189
2.
https://github.com/JetBrains/compose-multiplatform-core/blob/47af63a3986292608982f421bb345eb0a2032a98/compose/ui/ui-graphics/src/skikoMain/kotlin/androidx/compose/ui/graphics/SkiaBackedCanvas.skiko.kt#L141
3.
https://github.com/JetBrains/compose-multiplatform-core/blob/47af63a3986292608982f421bb345eb0a2032a98/compose/ui/ui-graphics/src/skikoMain/kotlin/androidx/compose/ui/graphics/SkiaBackedCanvas.skiko.kt#L128
4.
https://github.com/JetBrains/compose-multiplatform-core/blob/47af63a3986292608982f421bb345eb0a2032a98/compose/ui/ui-graphics/src/skikoMain/kotlin/androidx/compose/ui/graphics/SkiaBackedCanvas.skiko.kt#L189
5.
https://github.com/JetBrains/compose-multiplatform-core/blob/47af63a3986292608982f421bb345eb0a2032a98/compose/ui/ui-graphics/src/skikoMain/kotlin/androidx/compose/ui/graphics/SkiaBackedCanvas.skiko.kt#L211
among others.
**Next steps**
-> open pr in Compose Ui to use these more optimized functions
-> More optimizations on the Skiko side, Matrixes is a good example, CMP
and Skiko are processing Matrixes 2 times, toSkiaMatrix, which basically
is the same as a wrapper around FloatArray and then in the toInterop
method which copies the array (unavoidable). A good optimization would
be to just pass the Compose Matrix underlying `values` property which is
a FloatArray that toInterop accepts and so a lot of intermediate objects
and transformations could be avoided altogether

Part of [CMP-81](https://youtrack.jetbrains.com/issue/CMP-81) Check
Compose repositories for following JetBrains rules
and [CMP-82](https://youtrack.jetbrains.com/issue/CMP-82) Make a
contribution guide for Compose repositories

Partially reverts JetBrains/skiko#1117 (except excluding "Intel(R) HD
Graphics 4600")

Fixes
https://youtrack.jetbrains.com/issue/CMP-9352/Compose-doesnt-work-in-Parallels-Windows11-arm64

## Release notes
### Features - Desktop
- Cleanup old unpacked binaries from `~/.skiko`. Use
`skiko.data.cleanup.days` to configure the retention period in days

[SKIKO-1069](https://youtrack.jetbrains.com/issue/SKIKO-1069)
[libstdc++.so.6+0xdf9b4] std::__codecvt_utf8_utf16_base::do_unshift

It introduces symbol references to `GLIBCXX_3.4.22` (GCC 6.1.0 per
[doc](https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html)), which
should be fine

Binary size of binary is reduced by ~3MB

Reverts JetBrains/skiko#1114

Fixes https://youtrack.jetbrains.com/issue/SKIKO-1042/Support-ANGLE

The fix is the same as https://github.com/JetBrains/skiko/pull/1082,
except:
- the code is rearranged in new commits after resolving merge conflicts
(the merge is solved by applying their/ours)
- fixed "Task
':publishSkikoJvmRuntimeAngleWindowsX64PublicationToComposeRepoRepository'
uses this output of task ':signSkikoJvmRuntimeWindowsX64Publication'
without declaring an explicit or implicit dependency" (as in
https://github.com/JetBrains/skiko/pull/1127)

WIP: fix CI failure

## Testing
1. `./gradlew publishToMavenLocal`
2. In SkiaAwtSample:
```
./gradlew runWithAngleEnabled
```
3. [CI is
successful](https://buildserver.labs.intellij.net/buildConfiguration/Skiko_PublishSnapshot?branch=revert-1126-revert-1125-igor.demin%2Ffix-skiko-build-awtRuntimeElements&buildTypeTab=overview&mode=builds)

Reverts JetBrains/skiko#1126 with additional fixes

Fixes:
```
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.
```

Part of [SKIKO-530](https://youtrack.jetbrains.com/issue/SKIKO-530)
support for all platforms of awt-runtime in one jar

## Testing
- doesn't fail on configuration stage:
```
./gradlew publishAwtRuntimeElementsPublicationToMavenLocal -Pmaven.central.sign=true -Pmaven.central.sign.key=TEST -Pmaven.central.sign.password=TEST
```
- [CI is
successful](https://buildserver.labs.intellij.net/buildConfiguration/Skiko_PublishSnapshot/827040952)

In 0.9.36, there was a missing symbol that caused
```
libskiko-linux-x64.so: undefined symbol: _ZNSt19_Sp_make_shared_tag5_S_eqERKSt9type_info
```

It's because the build attempts to statically link the C++ standard
library, but:
- Skia's object files reference newer libstdc++ symbols
- GCC 7.3's `libstdc++` doesn't contain these symbols
- The static linking fails to resolve these symbols

GCC was downgraded from 9 to 7 in #1130 during the switch to AL2 to
provide better GLIBC compatibility.
Since AL2
[provides](https://docs.aws.amazon.com/linux/al2/ug/c-cplusplus.html)
only GCC 7.3 by default and GCC 10, installing GCC 9 is problematic
there, so it's bumped to 10

However, GCC 10 introduces outline atomics as default for new ARM chips,
the build might fail due to missing symbols like
```
org_jetbrains_skia_FontMgrWithFallback__1nDefaultWithFallbackFontProvider: error: undefined reference to '__aarch64_ldadd4_relax'
org_jetbrains_skia_FontMgrWithFallback__1nDefaultWithFallbackFontProvider: error: undefined reference to '__aarch64_ldadd4_acq_rel'
```
so, to keep things compatible with the previous GCC version,
`-mno-outline-atomics` option was added to disable this new behavior.

[SKIKO-1066](https://youtrack.jetbrains.com/issue/SKIKO-1066) Support
glibc 2.27
[CMP-9307](https://youtrack.jetbrains.com/issue/CMP-9307) Support glibc
2.27

- Added `linux-compat` docker image based on #1123. It works on both x64
and arm64 architectures
- `multistrap` tool was replaced by installing required packages inside
`linux-compat` and `linux-amd64` docker images
- `linux-arm64` uses GCC instead of clang (aligning between
distributions)
- GitHub checks now use precompiled docker images to reuse the same
environment
- `ci.yml` and `web.yml` were combined into `tests.yml`
- `publishToMavenLocal` checks are moved to `publish-dry-run.yml`
- Add building an Android sample as part of CI checks

---------
Co-authored-by: Vladislav.Ertel <vladislav.ertel@jetbrains.com>

In the compose hot reload project, we have seen races from multiple
tests trying to unpack skiko into the .skiko directory. Currently, the
library loading is only synchronized within the project. This MR also
adds a .lock file, which has to be locked when modifying the dataDir.

Note: This MR also changed the Library.load method from always entering
a monitor, to resolving an atomic reference, best case.

## Release Notes
### Fixes - Desktop
- Fixed a race condition that occurred when multiple processes attempted
to unpack Skiko binary files at startup

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.