This PR adds Windows Jump Lists support to AWT and fixes compilation on
Visual Studio 2022.

Co-authored-by: Ivan Matkov <ivan.matkov@jetbrains.com>

https://github.blog/changelog/2024-05-20-actions-upcoming-changes-to-github-hosted-macos-runners/

Updated to the latest version because otherwise the example in the
readme does not build because SkiaLayerRenderDelegate is missing

New API:

```kotlin
fun TypefaceFontProvider.createAsFallbackProvider(): TypefaceFontProvider
fun FontMgr.defaultWithFallbackFontProvider(fallback: TypefaceFontProvider): FontMgr
```

Usage:

```kotlin
val fontCollection = FontCollection()

val notoEmojiTypeface = Typeface.makeFromData(Data.makeFromBytes(notoEmojisBytes))
val fallbackProvider = TypefaceFontProvider.createAsFallbackProvider().apply {
    registerTypeface(notoEmojiTypeface)
}

fontCollection.setDefaultFontManager(FontMgr.defaultWithFallbackFontProvider(fallbackProvider))
```

<img width="400" alt="Screenshot 2024-06-07 at 14 48 28"
src="https://github.com/JetBrains/skiko/assets/7372778/76dc1330-d8e2-4be7-ad92-68214b058b4f">

Fix compose tests after #923

Add forgotten setter for linear metrics. Changed it to property.

Original functions have names
[`isLinearMetrics`](https://github.com/JetBrains/skia/blob/6726cd3e1ac4f30d6874c278008cdf24dfc9b470/include/core/SkFont.h#L115-L119C12)
and
[`setLinearMetrics`](https://github.com/JetBrains/skia/blob/6726cd3e1ac4f30d6874c278008cdf24dfc9b470/include/core/SkFont.h#L156-L163)

It's unconditionally de-ref the pointer that causes crash in case of
nulls


https://github.com/JetBrains/skiko/blob/c66eebc2c23a8b41eb618c715296c2a7dd135f43/skiko/src/jvmMain/cpp/common/paragraph/Paragraph.cc#L206

Fixes a couple of issues like:
https://github.com/JetBrains/compose-multiplatform/issues/4744 (TODO:
collect all references)

Before (slow-mo)


https://github.com/JetBrains/skiko/assets/1836384/5768b139-d08f-4142-8c14-2969107807f9



After (slow-mo)


https://github.com/JetBrains/skiko/assets/1836384/cc9a5103-3d30-412e-a5a4-baf590d657b8

Speculative fix for [a
case](https://github.com/JetBrains/compose-multiplatform/issues/4761),
where a lot of windows are created and dismissed.

Caches command queue per device [similar to
iOS](https://github.com/JetBrains/compose-multiplatform-core/pull/1127)

Speculative fix for [a freeze
issue](https://youtrack.jetbrains.com/issue/COMPOSE-1441/Desktop-skiko-freeze-after-sleep-on-Mac-with-multiple-external-monitors).

### Changes
Throw `RenderException` when constructing `Direct3DSwingRedrawer` with
`nullptr` device. (Similar to `Direct3DRedrawer`)

To avoid crash in:
```
DirectXOffscreenDevice *d3dDevice = fromJavaPointer<DirectXOffscreenDevice *>(devicePtr);
GrD3DBackendContext backendContext = d3dDevice->backendContext;
return toJavaPointer(GrDirectContext::MakeDirect3D(backendContext).release());
```

### Fixes

Speculative fix for crash with a stack head below:
```
---------------  T H R E A D  ---------------

Current thread (0x000001cbcb0793f0):  JavaThread "AWT-EventQueue-0" [_thread_in_native, id=16744, stack(0x0000009488c00000,0x0000009488d00000)]

Stack: [0x0000009488c00000,0x0000009488d00000],  sp=0x0000009488cfc670,  free space=1009k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  [skiko-windows-x64.dll+0x58afa]

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  org.jetbrains.skiko.swing.Direct3DSwingRedrawer.makeDirectXContext(J)J+0
```

### Note
I've found suspicious place in
```kotlin
// RedrawManager.kt:30
_renderApi = fallbackRenderApiQueue.removeAt(0)
_redrawer = redrawerFactory(_renderApi, redrawer)
```
Seems like `redrawer` is disposed twice if `redrawerFactory` throws
(both paths constructing `RedrawerManager` are affected).

@igordmn can you have a look?
It's a universal path for all desktop users, so I wonder why it didn't
backfire, if it's indeed incorrect.
May be it's because we don't really call `redrawerFactory` if a redrawer
was constructed correctly, so disposal of old one doesn't ever get
called in this context. I'm not sure where are the invariant boundaries
here.

To allow using OpenGL on macOs, call:
```
System.setProperty("skiko.macos.opengl.enabled", "true")
```

By request from user in DM who uses LWJGL+Skiko on macOS.

exists

## Issues fixed

Some CI don't have this library and when we run an application we have a
crash:
```
...\skiko-windows-x64.dll: Can't find dependent libraries
java.lang.UnsatisfiedLinkError: ...\skiko-windows-x64.dll: Can't find dependent libraries
	at java.base/jdk.internal.loader.NativeLibraries.load(Native Method)
	at java.base/jdk.internal.loader.NativeLibraries$NativeLibraryImpl.open(NativeLibraries.java:388)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:232)
	at java.base/jdk.internal.loader.NativeLibraries.loadLibrary(NativeLibraries.java:174)
	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2394)
	at java.base/java.lang.Runtime.load0(Runtime.java:755)
	at java.base/java.lang.System.load(System.java:1957)
	at org.jetbrains.skiko.Library.loadLibraryOrCopy(Library.kt:17)
	at org.jetbrains.skiko.Library.findAndLoad(Library.kt:111)
	at org.jetbrains.skiko.Library.load(Library.kt:56)
	at org.jetbrains.skia.impl.Library$Companion.staticLoad(Library.jvm.kt:12)
	at org.jetbrains.skia.Surface.<clinit>(Surface.kt:539)
	at androidx.compose.ui.test.SkikoComposeUiTest.<init>(ComposeUiTest.skikoMain.kt:172)
	at androidx.compose.ui.test.SkikoComposeUiTest.<init>(ComposeUiTest.skikoMain.kt:118)
	at androidx.compose.ui.test.SkikoComposeUiTest.<init>(ComposeUiTest.skikoMain.kt:139)
	at androidx.compose.ui.test.SkikoComposeUiTest.<init>(ComposeUiTest.skikoMain.kt:134)
	at androidx.compose.ui.test.junit4.DesktopComposeTestRule.<init>(DesktopComposeTestRule.desktop.kt:54)
	at androidx.compose.ui.test.junit4.DesktopComposeTestRule_desktopKt.createComposeRule(DesktopComposeTestRule.desktop.kt:41)
```

Reported in
https://jetbrains.slack.com/archives/C5VQN94SH/p1712564847131459?thread_ts=1712091431.760099&cid=C5VQN94SH

## Proposed changes
Load this library in runtime, and fallback to
`CreateSwapChainForComposition`

## Testing
1. Run Compose with transparent window:
```
import androidx.compose.foundation.layout.fillMaxSize
import androidx.compose.foundation.layout.padding
import androidx.compose.foundation.shape.RoundedCornerShape
import androidx.compose.material.Surface
import androidx.compose.runtime.mutableStateOf
import androidx.compose.runtime.remember
import androidx.compose.ui.Modifier
import androidx.compose.ui.draw.shadow
import androidx.compose.ui.graphics.Color
import androidx.compose.ui.unit.dp
import androidx.compose.ui.window.Window
import androidx.compose.ui.window.application
import androidx.compose.material.Text
import androidx.compose.runtime.*

fun main() = application {
    var isOpen by remember { mutableStateOf(true) }
    if (isOpen) {
        Window(
            onCloseRequest = { isOpen = false },
            title = "Transparent Window Example",
            transparent = true,
            undecorated = true, //transparent window must be undecorated
        ) {
            Surface(
                modifier = Modifier.fillMaxSize().padding(5.dp).shadow(3.dp, RoundedCornerShape(20.dp)),
                color = Color(55, 55, 55),
                shape = RoundedCornerShape(20.dp) //window has round corners now
            ) {
                Text("Hello World!", color = Color.White)
            }
        }
    }
}
```
Transparency should work, there shouldn't be errors in the log.

2. change `transparent = false`

Transparency shouldn't work, there shouldn't be errors in the log.

This should be tested by QA.

---------
Co-authored-by: Ivan Matkov <ivan.matkov@jetbrains.com>

skiko is supposed to be a wrapper around skia, however it has unrelated
features like input. This PR removes it from this library - it's
supposed to be handled externally.

- Removed `SkikoInput`, `SkikoKey`, `SkikoPlatform*Event`
- Replaced `SkikoView` to `SkikoRenderDelegate` and related field in
`SkiaLayer`
- `SkiaLayer` on macOS native now receives `NSView` instead of creating
it internally and attaching it to the `NSWindow`. In theory, it allows
initializing non-full-window skia view there (not tested)
- Updated samples and readme

Skiko extracts binaries to `~/.skiko` by default, but it is not always
possible. This PR adds a way to override the folder where to extract
binaries:
```
System.setProperty("skiko.data.path", File(System.getProperty("java.io.tmpdir")).resolve(".skiko").toString())
```

Fixes https://github.com/JetBrains/skiko/issues/885

The case seems rare - we only have a crash in tests reported. If we have
reports from real users, we have to change the default `~/.skiko` to
something else.

## Testing 1 (manual)
1. Run
```
import org.jetbrains.skia.Bitmap
import java.io.File

fun main() {
    val path = File(System.getProperty("java.io.tmpdir")).resolve(".skiko").toString()
    println(path)
    System.setProperty("skiko.data.path", path)
    Bitmap() // loads the library
}
```
2. See that `path` is created
## Testing 2 (manual)
The default way works:
```
import org.jetbrains.skia.Bitmap

fun main() {
    Bitmap() // loads the library
}
```

This is the skiko part of
https://youtrack.jetbrains.com/issue/COMPOSE-1149/wasm-js-Remove-media-events-from-Skiko

This commit introduces following changes:

 * CanvasRenderer is html-agnostic and deals with NativePointer
* SkiaLayer does not set any DOM dimensions of the canvas - it's up to
the user of the Skia to resolve this dimensions
 * Media event listeners are removed completely

Fixes https://github.com/JetBrains/compose-multiplatform/issues/4425

It is a regression after https://github.com/JetBrains/skiko/pull/858

The crash was because `d3dDevice->swapChain->GetBuffer` didn't return
the buffer to draw on if we reused the buffer from the previous frame
(we didn't change `surface` in case of zero size).

I am not completely sure why, but I exhausted my the investigation limit
and this fix is needed by other reasons (we need to wait for vsync).

## Testing
An additional check in the existed test (fails before the fix)

Merging a fix from `0.7.95.1` to the main branch for
https://github.com/JetBrains/compose-multiplatform/issues/4397

Now we build skia/icu with _skiko suffix to avoid clashes with Apple SDK

Corresponding skia change: https://github.com/JetBrains/skia/pull/3

Corresponding skia commit:
https://github.com/JetBrains/skia/commit/47d3027b8cbeea76135c0995d5886aa2e58e7512

It adds a fallback to the old initialization method in case of any
problems.

Instead, fallback to Software.

Discovered during https://github.com/JetBrains/skiko/issues/876
investigation

## Explanation

We throw RenderException, and Fallback mechanism catches it and switches
to Software

## Testing

1. Setup the system without OpenGL
2. Run SkiaSwingLayer
3. See the native crash

According to COMPOSE-939

And move Windows instructions to the first section

Commands for Linux were get from
https://github.com/JetBrains/skiko/blob/78f227f19bd4cb811d34fbc2df7befb4f76be355/.github/workflows/ci.yml#L102

Except we use `libx11-dev` instead of `xvfb`. Tested on a new system
(but I performed commands in other order, so I am not completely sure
that they are all needed)

* Include <cstdint> is required because of uintptr_t

* move `generateVersion` to common code

* on Linux with Chinese language chosen in interface this test fails

* this combination leads to NaN values when height is overridden

* test that empty font still have a meaningful metrics, because FontStyle may rely on it

* simplify test

* check that we don't put NaN in skia

this value might be used as part of key in paragraph cache, which may lead to UB atm

* Update skia version - m116-b54492e-1

* test windows

* Update skia version to m116-b54492e-3

It is a regression after https://github.com/JetBrains/skiko/pull/811

After that PR, OpenGL functions are linked in runtime via function `loadOpenGLLibrary`. We didn't call it in `makeGL` functions. Now we call.

Adding also `isLoaded` to avoid loading it multiple times

Fixes https://youtrack.jetbrains.com/issue/COMPOSE-642/Fix-Skiko-API-regression-for-creating-OpenGL-context