[iOS] Update podspec to use install_modules_dependencies

[cipolleschi]

This change updates the RNGestureHandler.podspec to consume the install_modules_dependencies function provided by React Native to configure the pods dependencies.
Thanks to using this function, whenever we update the function in React Native, the library will automatically benefit from it.
This will make the library more future proof and more resilient to changes in React Native

This allow RNGestureHandler to work also with frameworks, as before the change, it failed to build when use_frameworks! was set in RN 0.72.x

Test plan

Tested locally:

Before changes

1. Created a new app with npx react-native init RNFrameworks --version latest --skip-install
2. cd RNFrameworks
3. yarn add react-native-gesture-handler
4. yarn install
5. cd ios
6. NO_FLIPPER=1 USE_FRAMEWORKS=static RCT_NEW_ARCH_ENABLED=1 bundle exec pod install
7. open RNFrameworks
8. build and run and observe it failing because it can't find files in react/utils and react/debug

After Changes

1. Reinstall pods NO_FLIPPER=1 USE_FRAMEWORKS=static RCT_NEW_ARCH_ENABLED=1 bundle exec pod install
2. open RNFrameworks
3. build and run and observe it succeeding

[j-piasecki]

Thanks for taking the time to make a PR, we've known of the method for a while though 😅. The problem with it is that it was added in RN 0.71 IIRC, and at the moment we support RN all the way down to 0.64 (with plans to drop versions below 0.67 soon, but the problem persists in that case).

I could add a check for React Native version, but finding it out is prone to breaking in more custom configurations (like monorepos), or simply use the method only when USE_FRAMEWORKS=static is set. Do you have a preference on this (or a better approach)?

[cipolleschi]

Out of curiosity, why are you supporting down to 0.64, if we support only 70, 71, 72 and soon 73?
Wouldn't be better to align the support of the library to what we support in core?

Anyway, I think that for the time being, we can use the ruby's defined?() method to see whether that function exists and fallback to the prev implementation when it doesn't. I'll update the PR before EOD! :D

[cipolleschi]

updated! @j-piasecki

[j-piasecki]

Out of curiosity, why are you supporting down to 0.64, if we support only 70, 71, 72 and soon 73?

We supported 0.64 for quite a while as a min version, and from the time we started till now, there wasn't a meaningful reason to drop it since many people still used it. Recently we wanted to do a little overhaul of the GH's code, which would mean using some of the newer APIs - when that lands we plan to support 0.67 and higher since, again, there are a lot of people still using those versions and supporting them comes without much cost.

[uffou]

That's great! I will try to jumpstart 72 again after this is released.