Hook: allow source_<os> user-defines and path-like names for source: system

[santoshakil]

Two small additions to the build hook for apps that ship SQLite inside one of their own native libraries.

With source: system, a name is currently always turned into a platform file name (libfoo.dylib, libfoo.so, ...). That does not work for a library that is bundled as a framework on iOS, where the loader needs foo.framework/foo (or @rpath/...). Names with a directory component are now passed to the loader unchanged, absolute paths keep working as before and plain names are still mapped like today.

source and name can now also be given per operating system as a map (android: system, default: sqlite3 and so on; the existing name_<os> keys keep working). Our case, the Immich mobile app: a Rust library in the app already links SQLite with the compile options from this package's binaries and exports the sqlite3_* symbols, so on Android and iOS we point package:sqlite3 at that library (one copy of SQLite in the app) while flutter test on the host keeps the default download.

Tests added in test/hook/description_test.dart for the path-like names (framework partial, @rpath/..., plain name still mapped) and for the per-OS maps (the iOS entry vs default, and a map without an entry for the target OS). The existing download url test now passes a code config since the source lookup needs the target OS. Docs in doc/hook.md and a changelog line.

Tried it in our app on an iPad simulator: the manifest entry becomes ["system", "immich_core_ffi.framework/immich_core_ffi"], no sqlite3.framework in the bundle, and sqlite3_libversion resolved through the sqlite3 asset lives in the same loaded image as our Rust library.

[simolus3]

I really wish hooks had a way to configure this out of the box, but since they don't I feel it makes sense to adopt something in the package itself 👍