feat: layered app files, code from the APK, code cache in code_cache - #2104

Give AppFiles the runtime's app file reads: IsFile, ReadText and Open
(a Reader with size() and read() into caller-owned buffers). A path under
<files>/app, <files>/internal or <files>/metadata is normalized - "//",
"." and ".." collapsed, /data/data/<pkg> and /data/user/0/<pkg> spellings
mapped onto the canonical files root - and served from an ordered list of
sources; anything else reads the real file system unchanged. The only
source for now is the files directory itself.

Route through it: module stat/read for CommonJS, ES modules and JSON
(ModuleInternal, ModuleInternalCallbacks), Runtime::RunScript and
ReadFileText (still under the debug file-write lock), the inspector's
package.json and network-resource reads, and the metadata streams, which
are read into the same caller-allocated buffers. The direct-boot opendir
guard and .so dlopen paths are unchanged.

Add com.tns.AppFiles: static natives over the native AppFiles (init,
filesRoot, appRoot, logicalPath, isFile, readText) that need only the
loaded library, not an initialized Runtime. RuntimeHelper initializes it
right after System.loadLibrary, before AppConfig is built; Module.init
initializes it too for embedders that start the runtime another way.

Route the Java-side reads through it: Module's file/directory probing,
package.json reading and folder-module cache keys, AppConfig's
package.json, Runtime.runScript's existence check and RuntimeHelper's
tns-java-classes.js check. package.json is now decoded as UTF-8 rather than
with the platform default charset.

Behaviour change: Module.resolvePath canonicalizes only the files root.
Paths inside it are normalized lexically ("//", "." and ".." collapsed,
/data/data and /data/user/0 spellings unified), so symlinks under the app
directory are no longer resolved to their targets. Paths outside the files
directory are still canonicalized.

Move V8 code caches out of the app directory, from <script>.cache and
<script>.mcache next to the source, to
<code cache dir>/v8/<FNV-1a 64 of the logical path>.{cache,mcache}.
Android clears that directory on app and OS updates and treats it as
clearable cache. Java passes getCodeCacheDir() to AppFiles.init; Module.init
falls back to <data dir>/code_cache.

Entries are validated by content instead of mtime: a header carries a magic,
a format version, the length and zlib crc32 of the exact source text V8
compiled, and the payload length and crc32 (release V8 skips its own
checksum). Any mismatch compiles without the cache and rewrites the entry,
and so does an entry V8 rejects, now on the CommonJS path as well as the
ES module path. Writes go to a mkstemp file in the same directory and are
renamed into place; mkdir and write failures are ignored (direct boot, a
full disk). The utime/mtime logic is gone.

Still gated by the codeCache option, default off. The test app turns it on
so the suite exercises it; new specs cover the round trip, a payload
checksum failure, a V8 rejection and a deleted cache directory, each load
in a fresh worker.

File.{h,cpp} lost its last users and is removed.

With "android": { "loadCodeFromApk": true } in app/package.json, code is no
longer extracted to <files>: .js, .mjs, .cjs and .map under app/ (minus
the android.alwaysExtract globs, relative to app/) and everything under
internal/ and metadata/ are read straight from the APK's assets. JSON,
.so files, fonts, images and everything else under app/ are still
extracted. The flag and globs are read from the APK's own copy of
app/package.json, never through the app file sources, so a LiveSync'd
package.json cannot change where code comes from.

AppFiles gains an APK source (AAssetManager held for the process; one
AAssetManager_openDir listing per directory, cached under a mutex; one
AAsset per open) and a single predicate, IsApkServed, that both the
extractor and the sources use. The files directory is searched first and
the APK second, in every build type, so code LiveSync or the app itself
writes into files/app wins over the APK's copy. Without the flag nothing
changes: one disk source, everything extracted.

Because extracted files win, a new assets thumb must leave none of the
previous version's behind: with the flag, files/app, files/internal and
files/metadata are deleted and only app/ is extracted, minus the
APK-served set. If any of them cannot be deleted, that is logged and all
assets are extracted over them, code included, as without the flag. The
native extractor takes whether to skip the APK-served set as a parameter. When a plugin takes over
extraction (Util.runPlugin returns true) nothing is extracted or deleted,
as before, and code still resolves through the sources.

Also:
- metadata is read through AppFiles::Open into the same len + 512KB
  buffers; the direct-boot opendir guard checks the files directory
  instead of files/metadata when metadata comes from the APK;
- the ES module resolver keys modules by the logical path, so the
  /data/data and /data/user/0 spellings name one module;
- dlopen gets the real file behind a logical .so path;
- AndroidJsV8Inspector.getPageResources tolerates unreadable directories
  and an app directory with no files;
- AppFiles.appRoot() is removed from Java (unused).

Make the app file sources a list that plugins can change before the runtime
starts. A layer is a closed, immutable descriptor (AppFileLayer):
directory(dir), apkAssets(assetBase) or map(path -> file | asset |
whiteout), with paths relative to the app root; customizer layers never see
internal/ or metadata/. The built-in layers keep the ids "extracted" and
"apk" (the latter only with android.loadCodeFromApk).

Customizers implement AppFileLayersCustomizer { int priority();
void customize(AppFileLayers.Builder) } and are registered androidx.startup
style:

  <meta-data android:name="com.example.MyCustomizer"
             android:value="org.nativescript.AppFileLayersCustomizer" />

RuntimeHelper instantiates them by reflection before extraction and runs
them in ascending priority. The builder starts from "extracted" above
"apk" and exposes the context, isDebuggable, isAppUpdated,
loadsCodeFromApk, the layer ids and insertAbove/insertBelow/remove. In
debuggable builds "extracted" is pinned back on top afterwards so LiveSync'd
files always win; release builds have no LiveSync, so there a customizer may
deliberately place a layer above the extracted files. A customizer that
cannot be created or that throws (including a LinkageError from a missing
dependency) is logged and skipped. The resulting list is handed to native
once, as flat arrays.

A map entry whose file or asset does not exist falls through to the layers
below; only a whiteout hides them.

Layering only affects runtime-mediated reads (modules, JSON, source maps);
files other code opens by path, such as fonts and images, are not layered.

The test app registers a customizer with a map, a directory and an APK
asset layer, covered by tests/testAppFileLayers.js.

With "android": { "storeCodeUncompressed": true } in app/package.json, the
app template adds .js, .mjs, .cjs, .map and the three metadata streams to
androidResources.noCompress, so they are stored in the APK and
loadCodeFromApk reads them without inflating. It costs APK size and is
independent of loadCodeFromApk, though it only pays off together with it.

noCompress matches by file-name suffix across the whole APK, not only under
assets/app, which is why the metadata streams are listed by full name
rather than as ".dat". The list is exposed as
project.ext.nsUncompressedCodeSuffixes.

The suite can now be run in three modes from the repo root:

  ./gradlew runtestsAndVerifyResults
  ./gradlew runtestsAndVerifyResults -PloadCodeFromApk
  ./gradlew runtestsAndVerifyResults -PloadCodeFromApk -PstoreCodeUncompressed

The properties are forwarded to the test app build, where
tools/appfiles-test-mode.init.gradle sets the flags in the packaged
app/package.json (and applies the exported noCompress list) without
touching the source package.json. The init script is always applied and
adds the mode as an input of the asset merge, so switching modes rebuilds
the packaged assets.

tests/testLoadCodeFromApk.js covers, in both modes: runtime files, a
getFilesDir()-spelled runScript, require and import under both
/data/data and /data/user/0 spellings (one module each), and the
android.alwaysExtract escape hatch, which the test app now uses. With the
flag on: no code under files/app beyond the alwaysExtract match, JSON and
images still extracted, no files/internal or files/metadata, a worker
loading APK-served code, and a file written into files/app under the
runtime lock (as LiveSync does) winning over the APK copy until deleted.