Ship the iOS and web PDFium binaries inside the published artefacts

[kdroidFilter]

Closes #11.

Summary

Consumers of dev.nucleusframework:pdfium hit ld: library 'pdfium' not found on iOS and Can't resolve './pdfium_glue.mjs' on web — the published klibs shipped the Kotlin bindings but not the binaries the linker and the bundler need. Android and JVM already embedded theirs.

iOS — a static archive packed into the klib

• pdfium.def declares staticLibraries = libpdfium.a with per-target libraryPaths, so cinterop packs the archive into default/targets/<target>/included/. The machine code travels with the artefact: no -L, no ThirdParty/ drop, no pdfium.framework to embed, nothing to codesign, no extra Xcode build phase.
• bblanchon publishes Apple platforms as a .dylib only, and a dylib cannot be carried this way. The one prebuilt static archive available (paulocoutinhox/pdfium-lib) is compiled against Chromium's bundled libc++ but ships none of its objects, so it fails to link against Apple's libc++ with undefined std::__Cr:: symbols.
• NucleusFramework/pdfium-binaries therefore runs bblanchon's own build harness with build_type=static — which sets pdf_is_complete_lib = true and use_custom_libcxx = false, the combination that makes the archive self-contained. It syncs from upstream daily and publishes an ios-static-<build> release per PDFium version (stripped: 16 MB per slice instead of 268 MB). :pdfium:installPdfiumIos downloads the one matching the pdfium-bblanchon pin.
• pdfium-auto-release now defers a version bump until the matching static build exists, so master never points at a version the iOS cinterop cannot resolve.

Web — assets at the archive root

• pdfium.wasm, pdfium_worker.mjs, pdfium_runtime.mjs and pdfium_glue.mjs are published at the resource root instead of a nested pdfium/ directory, and the glue is eval'd from Kotlin rather than imported, so webpack no longer has to resolve ./pdfium_glue.mjs and consumers need no copy task.

Removed

• The dev.nucleusframework.pdfium Gradle plugin and its includeBuild, its CI publishing steps, EmbedPdfiumDylibTask, the klib zip-surgery task, and the LIBRARY_SEARCH_PATHS workaround in Config.xcconfig. The Xcode phase is back to the stock embedAndSignAppleFrameworkForXcode.

Test plan

• :pdfium:check passes (includes the new packagingTest)
• packagingTest asserts libpdfium.a inside both published cinterop klibs, no -lpdfium in the manifest, and the four web assets at the archive root — wired to the …Cinterop-pdfiumKlib packing tasks so it reads the artefacts consumers actually get
• Published klibs are 7.0 MB each with the archive inside
• :example:linkDebugFrameworkIosArm64 and …IosSimulatorArm64 link with isStatic = true
• Same with isStatic = false (the configuration reported in Missing binaries #11); otool -L shows no libpdfium dependency and the FPDF code is inside the binary
• Run the example app on a device

Note

Upstream builds the iOS objects with minos 17.0, so apps targeting below iOS 17 get a benign ld: warning: object file was built for newer iOS version. That was already the case with the dylib.