[modules][ios] Group together some common exceptions (#18732)

[modules][ios] Use JSI to call native methods on legacy modules (#18438)

[e-m-c][ios] Expose `NativeModulesProxy` config as a JSI module (#17741)

- Created the `NativeProxyModule` - a Sweet expo-module which is a counterpart of the `NativeUnimoduleProxy` RN module (`EXNa

[e-m-c][ios] Expose `NativeModulesProxy` config as a JSI module (#17741)

- Created the `NativeProxyModule` - a Sweet expo-module which is a counterpart of the `NativeUnimoduleProxy` RN module (`EXNativeModulesProxy`)
- it is registered manually in `ExpoBridgeModule`, right after the creation of `AppContext`
- currently, it only exports constants - the same as the `EXNativeModulesProxy` module
- the constants creation logic is still written in Objective-C inside `EXNativeModulesProxy`. It will finally be migrated in the future, but there's no reason to move it in this PR.
- Refactored config creation in `EXNativeModulesProxy constantsToExport`
- created the `EXModulesProxyConfig` class - a store for the module proxy config + some convenience methods for dictionary management
- config for both legacy modules and new sweet expo-modules is now lazy-loaded and cached
- minimized Swift calls from Objective-C, as they were performance bottlenecks - now there is only one such call.
- Yet, both configs are loaded in `NativeModulesProxy.native.ts` - config constants are taken from the JSI module first (with fallback to legacy constants), but method calls are still handled by the legacy proxy module.
- We need to load both (or at least the legacy one) anyway, but this shouldn't be a big issue for now, because the config is created only once and cached.

show more ...