To extract Skottie and other extensions from Skiko core, we need to
expose certain private symbols from skia. This requires creating tasks
to control the visibility of Skia symbols.

To control visibility of symbols the following things were applied:

### JVM
We are generating a lists of symbols that we want to export. To obtain
the symbols we're doing the following:

1. Collecting all globally defined symbols from the core Skiko/Skia
inputs: Skia static libraries plus core object files.
2. Collecting all undefined symbols from extension/module inputs. These
represent symbols that extension modules need the core library to
provide.
3. Adding JNI infrastructure symbols from the core exports, such as
`Java_`, `JNI`, and `jvm`, so the JVM can still find the native entry
points.
4. Intersecting the extension imports with the core exports. The result
is the list of core symbols that should stay exported.

Generated symbol list it then passed to the linker which hide symbols we
don't need to have visible.

### Native 
For Native targets, Skia is linked into the final produced binary rather
than exposed as a shared "core" library that extension modules link
against. Because of that, Skia symbols do not need to remain externally
visible for other Skiko modules to resolve against them.
Since we are going to build Skia from our fork with Skia symbols public
by default we need to hide them on native.

### WASM
This PR does not include wasm parser as we don't need it. We can first
create the wasm binary for extension functions and then provide them
when compiling the core. This will allow to export only symbols that are
needed by the extension modules automatically. This will be introduced
in the PR with Skottie extraction.

Closes [SKIKO-1142](https://youtrack.jetbrains.com/issue/SKIKO-1142)