Fixed new arch support

[scarlac]

Oh boy.

Changes

1. Fixed SafeAreaView dummy support on iOS
2. Fixed zoom issue
3. Fixed Fabric (new arch) compile issues on both platforms Fixed included broken codegen lib code
4. Fixed broken .h import paths to avoid setting custom build settings Fixed potential memory issue by disabling view recycling Added Fabric (new arch) support for camera view component Added RN 0.81 for example
5. Added RN 0.79 for main lib
6. Added helper for re-running codegen
7. Added gitignore for Android codegen making a podspec Added support for scanThrottleDelay on Android
8. Added includesGeneratedCode to package.json to indicate changes Rewrote optional int props to use -1 instead due to RN bug Moved to Obj-C with C++ support (.mm) to avoid C++ compile issues

Why

New arch support was broken

Background

The new arch is mainly 2 components from our stand point:

1. "Modules" - APIs you can call: This was OK
2. "Fabric" - View components: This was broken

The new arch support was generously contributed, however as the new arch has changed, so has the APIs we need to use, the tooling, and the code we need to write, and the code we wrote.
For reasons that aren't clear, the view component was probably never working on iOS, and possibly never on Android either. It's a wonder it even compiled as dead code.

There are a multitude of issues that I am addressing with this PR, but it centers around Codegen.
Codegen is really broken and needs some attention, as it's at the heart of the new arch.

Codegen doesn't work out of the box

1. By default, codegen generates code as if it was a stand-alone application. Perhaps this is a good default but if app owners aren't supposed to run it, I wonder why it's not optimized for library authors. Ideally it should detect the includesGeneratedCode setting and base its behavior on it (warn/error/generate differently). But it does not.
2. By default, codegen generates codes into an inconvenient shared location for both android and iOS. A library is allowed to include generated code in its pod (includesGeneratedCode), in a custom folder, which seems like an overall better solution, but it's not the default as RN team is very forward looking where it's all generated on-the-fly. This custom-directory and include-generated-code approach seems to generally not be very well documented
3. On Android, codegen makes a cocoapod file, which serves no purpose
4. How android/build.gradle must be updated is undocumented, but I found that using a flag served no purpose despite what others are doing
5. On iOS, codegen makes view component numeric optional properties that default to 0 instead "undefined".
   This broke the zoom, maxZoom, and a few other properties. This wasn't directly fixable. The PR rewrites everything to use -1 as a stand-in for undefined view properties where necessary. The community is aware of this shortcoming but there is no fix in sight:
   Fabric component: codegen drops optional state for component properties and in events properties facebook/react-native#49920 (comment)
6. There are like ~5 different ways to run codegen (npx rnc/cli, react-native codegen, node node_modules ..., ./gradlew ...), and none of them respect the settings in package.json, but each of them does something slightly different, and one of them doesn't work for libraries. The documentation is scattered across the internet, and it's not clear which of them is the right one, so I picked one.
7. Codegen no longer generates code for DirectEventHandler handlers, causing several things to break in our existing iOS code
8. cmakeListsPath seems to be a requirement that should match codegen, but you have to guess how it works because docs are (also) missing for this
9. Codegen makes a broken CMakeLists.txt file that causes the consuming app to crash on startup with a opaque segmentation fault. Through debugging it turns out target_compile_reactnative_options is the solution in 0.80 and newer, but in older apps you need the old crashy code. This was only technically documented in a blog post, and is technically a thing that can break if you decide to use "includesGeneratedCode". It would have been nice if they had included this in codegen instead of/in addition to writing a blog post about it.

In addition to this, the docs can easily lead to issues in your library because of documentation like this:
https://github.com/reactwg/react-native-new-architecture/blob/main/docs/fabric-native-components.md

iOS: Create the .podspec file

[...]
s.source_files    = "ios/**/*.{h,m,mm,swift}"

Pay special attention to how header files are included here. This causes issues like unable to find files like:

#include <functional>

and

#include <memory>

Which are C++ standard library stuff, which I could guess, but unfortunately all the AIs in the world will also tell you. They will lead you down a path of trying to add C++ support to your pod, but the truth is in these issues instead:
CocoaPods/CocoaPods#12105 (comment)
facebook/react-native#45424 (comment)
TLDR: Don't include .h files next with .swift files. Swift compiler can't handle it.