feat(frida): expose Scope::Full + Process::get_parameters

[jhasheng]

What

Exposes two pieces of frida-core that the safe wrapper currently can't reach:

1. FridaProcessQueryOptions scope. frida_device_enumerate_processes_sync takes a query-options arg that the wrapper hard-codes to null (≡ FRIDA_SCOPE_MINIMAL). Adds a Scope enum and Device::enumerate_processes_with_options(scope).
2. frida_process_get_parameters returns a GHashTable<gchar*, GVariant*>. Process::get_parameters walks the hash and returns HashMap<String, Variant> (typical keys on Windows: ppid, path, user, started).

Existing Device::enumerate_processes() is unchanged — still Scope::Minimal, no breakage for current callers.

Why

Hooking Chromium-style multi-process apps (Chrome, Electron, Discord, WeChat/Weixin, VSCode, ...) needs to pick the main process out of N same-named entries. The info is in frida-core's parameter table (ppid), but Rust callers can't see it today.

Real use case:

let procs = device.enumerate_processes_with_options(Scope::Full);
let same: Vec<_> = procs.iter()
    .filter(|p| p.get_name() == "Weixin.exe")
    .collect();
let pids: HashSet<u32> = same.iter().map(|p| p.get_pid()).collect();
let main = same.iter().find(|p| {
    p.get_parameters().get("ppid")
        .and_then(|v| v.get_int())
        .map(|ppid| !pids.contains(&(ppid as u32)))
        .unwrap_or(false)
});

Side changes (required for the above to actually work)

• Variant::from_ptr previously todo!()'d on unknown GVariant signatures. That crashes the moment frida hands you something the wrapper didn't anticipate — e.g. Windows packs process icons as "ay" byte arrays, so get_parameters() panics on the first one. Replaced with Variant::Unsupported(String) carrying the original sig; callers decide whether to skip or decode externally.
• New numeric GVariant signatures. Previously only "x" (Int64) was decoded; added y n q i u t all widened to Int64 (i64 covers u32 / i32 / u64-up-to-i64::MAX comfortably). ppid arrives as "u", so this is a hard prerequisite for the new get_parameters to return anything useful.

Demo

A new example examples/core/get_process_parameters walks the API:

```text
$ cargo run -p get_process_parameters -- Weixin.exe
★ main pid= 15840 ppid= 12888 D:\Tencent\weixin_4.1.2.17\Weixin.exe
helper pid= 6964 ppid= 15840 D:\Tencent\weixin_4.1.2.17\Weixin.exe
helper pid= 15892 ppid= 15840 D:\Tencent\weixin_4.1.2.17\Weixin.exe
helper pid= 25400 ppid= 15840 D:\Tencent\weixin_4.1.2.17\Weixin.exe
```

Tested

Manually against Weixin 4.x on Windows 11. Round-trip works; ppid filter correctly picks the main process (PID 15840) out of 4 `Weixin.exe` instances where the other 3 are `--type=wxocr/wxplayer/wxutility` helpers.

Compatibility

• No breaking changes. All existing public APIs keep their signatures.
• New `Scope` and `Variant::Unsupported` are additive.
• MSRV / dependency surface unchanged.

[s1341]

Thanks! would it be possible to add a test so we can check this new functionality in CI?

Also, please address CI issues.

[s1341]

Thanks! Looks good.