Support `SHARED FRAMEWORK` targets in CMake RN

[kraenhansen]

We're currently expecting CMake projects to output "free" dynamic libraries (not wrapped in Apple frameworks) and it would be great if we supported use-cases where developers wants to control the framework options and skip the transformation from dynamic library to framework that CMake RN performs.

Documentation for CMake's support for outputting frameworks: https://cmake.org/cmake/help/latest/prop_tgt/FRAMEWORK.html

add_library(dynamicFramework SHARED
            dynamicFramework.c
            dynamicFramework.h
)
set_target_properties(dynamicFramework PROPERTIES
  FRAMEWORK TRUE
  FRAMEWORK_VERSION C
  MACOSX_FRAMEWORK_IDENTIFIER com.cmake.dynamicFramework
  MACOSX_FRAMEWORK_INFO_PLIST Info.plist
  # "current version" in semantic format in Mach-O binary file
  VERSION 16.4.0
  # "compatibility version" in semantic format in Mach-O binary file
  SOVERSION 1.0.0
  PUBLIC_HEADER dynamicFramework.h
  XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer"
)

It would be great if we added documentation and tests for this as well 🤞

[shirakaba]

The NativeScript repo was originally producing a libNativeScript.dylib (or libNativeScript.0.1.0.dylib, if BUILD_FRAMEWORK were TRUE rather than FALSE), which it renamed to NativeScript.node for use with Node.js.

I ended up changing this to a .framework for consistency with the iOS side of things. Though would've been interesting if react-native-node-api could've handled either (somehow).

[kraenhansen]

I'm starting to think of another issue. The way we're handling XCFramework might not be ideal if the author wants to sign their binaries 🤔
I'm contemplating if we should ease requirements of these prebuilds and instead provide the requireNodeAddon function with enough information to handle XCFrameworks regardless of how they're built (as long as they expose a dylib which use Node-API to register an addon).

And then have "opt-in" helpers for renaming to avoid clashing names when linking 🤔 To be honest - most of that requirement is driven from the hope of being able to run the Node.js tests and examples without requiring code-changes ...

[kraenhansen]

I've started work on this and will likely take it even further to the point of requiring CMake projects to set FRAMEWORK TRUE their shared object libraries. I'll extend gyp-to-cmake with an option to emit this configuration in the CMakeList.txt for the GYP projects to be compatible and I'll make sure to update examples in the repo to match this new expectation.

We could also provide an includeable .cmake file with a function to make that easier (like we do for weak-node-api) if this is causing too much friction.