Add atomicfu plugin and use it to implement all atomics

[m-sasha]

Proposed Changes

As atomicfu atomics are now stable, we can use them to implement AtomicReference, AtomicInt etc.

I made the changes module-by-module, so it could be more convenient to review commit-by-commit.

Breaking change

This will break code in the specific source-sets that was using the public actual.

The list of types that were public and are now internal:

• androidx.compose.runtime.AtomicReference in JS, native and WASM source-sets.
• androidx.compose.foundation.AtomicLong in JS, WASM and native source-sets.
• androidx.compose.material.InternalAtomicReference in JS and native source-sets.

Testing

Test: Waiting to see the tests in CI.

[github-actions]

Test Results

66 tests  ±0   66 ✅ ±0   0s ⏱️ ±0s
10 suites ±0    0 💤 ±0 
10 files   ±0    0 ❌ ±0 

Results for commit 7738b42. ± Comparison against base commit ba6c6d4.

♻️ This comment has been updated with latest results.

[igordmn]

Let's add ## Breaking change to the PR description. It will be added manually to the changelog later (or via some future script)

[igordmn]

actual was a (public) class (not a typealias) and it was using the declaration

We should write it from the user perspective. The user sees only available classes, not that there are aliases/actuals. We should enumarate all removed classes and sourceSets (jsMain, iosMain, wasmMain).

[igordmn]

@eymar, could you also look at the PR?

• we are adding atomicfu, as atomic's are stable - it transforms them into actual classes during compilation, and uses a stable API for Wasm
• we are removing public AtomicInt/etc from native/js code (from commonMain we removed in https://android-review.googlesource.com/c/platform/frameworks/support/+/2875994, in the stable desktop it was internal)

[eymar]

I see the source set here named jbMain. I understand that we added jbMain in runtime module, because skikoMain name doesn't fit runtime purpose and it doesn't depend on skiko.

Since animation-core depends on ui, then it depends on skiko:
implementation(project(":compose:ui:ui"))

And the name can be skikoMain to not introduce a new name beside runtime. Not a big thing though. No skiko code is used here directly, so skikoMain name here is arguable.

[eymar]

if suggestion by Igor above to be applied, then here it's similar:

desktopdMain.dependsOn(jbMain)
jsNativeMain.dependsOn(jbMain)

[eymar]

Intereseting. Wasn't https://android-review.googlesource.com/c/platform/frameworks/support/+/2875994 a breaking change? I see no api files changes in it.

[igordmn]

Wasn't https://android-review.googlesource.com/c/platform/frameworks/support/+/2875994 a breaking change?

Only for native/js. For desktop/Android it was internal. It was available in commonMain, but it wouldn't compile, because the actual was internal. Discussion