Derive target and triplet lists instead of hardcoding them (cmake-rn, ferric) #417

Grouping four TODOs that all come down to the same thing: the set of targets we build for is hardcoded or guessed, rather than derived from the toolchain and the project being built.

cmake-rn: default triplets are a heuristic

In current-development mode both platforms guess which device the developer is targeting instead of asking:

https://github.com/callstackincubator/react-native-node-api/blob/29a527d87fa8cb965b0048b1b4c1cff2b0eab281/packages/cmake-rn/src/platforms/android.ts#L106-L109

Apple always returns arm64;x86_64-apple-ios-sim, so a developer iterating against a physical device or a tvOS/visionOS simulator silently builds the wrong slice. Android infers the ABI from process.arch, i.e. from the host architecture, which is wrong whenever the running emulator's ABI differs from the machine's. Both could be replaced with a probe — xcrun simctl list devices booted --json and adb devices + adb shell getprop ro.product.cpu.abi respectively — falling back to today's heuristic when nothing is booted.

cmake-rn: no default triplets at all outside the env var

As the TODO notes, this matters most when the build is driven from within a React Native app package, where the app's own configuration already says which platforms and architectures are in play.

ferric: hardcoded Apple target list

The list has to be kept in sync with Rust's supported targets by hand, and the commented-out Catalyst entries show it already drifting. Either query rustup target list or take the list from @napi-rs/triples.

These can land separately; they are filed together because a fix for one informs the shape of the others.