* [awt.metal] Extract MetalDevice interface into .h file

* [awt.metal] Move context and renderTarget creation to ContextHandler

ContextHandler shouldn't depend on redrawer, since redrawer depends on ContextHandler

* [awt.metal] Use value class to hold MetalDevice pointer

* [awt.metal] Add docs for MetalDevice

* [awt.metal] Add simple docs for MetalRedrawer and MetalContextHandler

* [awt.metal] Use null instead of artificial pointer to 0

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

* Update docker linux-emscripten-amd64

Install necessary libs + update emcc 3.1.35

* Update Dockerfile

* allow to configure logger in example applications

* use `layer.backedLayer` position and size as source to update CALayer

* non zero layer origin test

* Expose u_charDirection

* Move CharDirection to icu package

* Add doc comment for CharDirection

component listeners are performed to late so for absolute positioning we need to stick with `doLayout`

This reverts commit 2147b0e7.

* Add invalid unicode text that detects interop issue

* Remove utfToUtf8 function

* Fix JVM invalid unicode strings interop

* Update invalid unicode unit test

* Fix formatting and add more comments

1. Remove SkikoTouchEvent, we send all pointer events as SkikoPointerEvent now.

2. Add SkikoPointerEvent.Pointer that represents a separate touch/mouse

3. Implement multitouch for iOS/Android

* sometimes when we change scale via `EasyRes` or when we close/open lid and window is migrated to other screen `paint` is not called

see FL-18544

* customizable logger behaviour

* add debug logs in AWT layer

* migrate to m110

* use skia m110-ad42464-1

---------
Co-authored-by: Oleksandr Karpovich <a.n.karpovich@gmail.com>

* Add more prerequisites for building

* Xcode CLI is applicable to macOS only

* prevent usage of dangling pointer to `MetalDevice`

MetalRedrawer may be disposed during update which leads to use after free

* add test and comment

…on Windows

First off, I don't think there was any need for the repeated checks for device pixel ratio changes via checkContentScale because we should be able to rely on the graphicsContextScaleTransform property from AWT.

I removed the corresponding code and changed contentScale to directly return the platform-specific implementations from the toolkit/device. There's also no need to cache the value because the device and the graphics configuration already does it for us.

Secondly, there was a layout glitch on Windows when moving windows between monitors with different device pixel ratios. A fix has to happen directly in the JBR, but for now I created a semi-cheap workaround. See this issue and the linked ones for details: https://youtrack.jetbrains.com/issue/JBR-5259/Canvas-is-painted-at-the-wrong-position-after-dragging-JFrame-to-a-monitor-with-different-scale

* Update docs about development on Windows

Specified a more detailed manual how to install Visual Studio. I checked it on a clean PC.

* Update DEVELOPMENT.md

* Update DEVELOPMENT.md

* added performance test with clocks

ignore tests with clocks

* use simple logger instead of printlns

* checked that we call `finishRecording` at the same picture that we called a `beginRecording`

* make `Logger` internal

* disable assertions in rendering performance test with content; otherwise it might be too flaky

* unignore `FPS is near display refresh rate (multiple windows with clocks)`

Co-authored-by: Steyn Geldenhuys <steyn.geldenhuys@sieveo.com>

... and make software renderers respect the pixel geometry

We accidentally didn't prepare the SurfaceProps into an IntArray when passing them down into the JNI in the Windows version. The memory layout must have accidentally matched between both representations on Windows 10, but it doesn't work on Windows 11 for some reason. This is the proper fix.

* Use gradle 7.6

* add plugin repositories

* add plugin repositories

Deadlock:
[AWTThread] awtLock -> SkiaLayer.dispose -> LinuxOpenGLRedrawer.dispose -> we are here -> lockLinuxDrawingSurface -> awtLock
[refreshRate updater thread] -> lockLinuxDrawingSurface -> we are here -> awtLock

We moved refreshRate to another thread, and check it only once a second, because it is not fast. I mistakenly thought in the past, that it is very slow on Linux (2ms), but it appears it was because of the awtLock itself. In the AWT thread it take 0.2ms, that is also slow for just one functions, but bearable, if it called only once every second.

Alternative is to subscribe to the native XRRScreenChangeNotifyEvent: https://www.x.org/releases/current/doc/man/man3/Xrandr.3.xhtml. But it seems X window system can have only one event queue associated with the window, and we already have one inside AWT, and we don't have access to it.

* `managedString` might be inlined and garbage collected before the beginning of JNI call

* add other missed `reachabilityBarrier`s

* align `nMakeFromBackendRenderTarget` signature with kotlin counterpart

* transfer `SurfaceProps` only via intArray

* rename `SurfacePropsObj` to `SurfacePropsInts`

* take `SurfaceProps` into account in `js/MakeFromBackendRenderTarget`