Summary:
fixed homepage url in package.json file of community cli plugin.

## Changelog:
[GENERAL][CHANGED] - changed community cli plugin homepage url.
<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests

Pull Request resolved: https://github.com/facebook/react-native/pull/42696

Test Plan: community-cli-plugin homepage url must be opened correctly.

Reviewed By: rubennorte

Differential Revision: D53179709

Pulled By: huntie

fbshipit-source-id: 7949a897d4fe1da228fce323fa8bb32640194273

Summary:
Just small fix for those who are copy & pasting commands from error message.

## Changelog:

[INTERNAL] [CHANGED] - Update erorr message to use `npx` when calling `react-native`

Pull Request resolved: https://github.com/facebook/react-native/pull/42691

Test Plan: _

Reviewed By: cipolleschi

Differential Revision: D53177186

Pulled By: cortinico

fbshipit-source-id: e680cde81fde1f560dfeb1a85c8ad90090d69653

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42586

Every event name must be normalized.

The normalization strategy is:
1. If it starts with `top` -> do nothing.
2. If it starts with `on` -> replace `on` with `top`.
3. Else -> capitalize the first character and prepend `top`.

We have it for the old renderer on iOS [here](https://github.com/facebook/react-native/blob/a7586947d719a9cd2344ad346d271e7ca900de87/packages/react-native/React/Base/RCTEventDispatcher.m#L12-L21). This one is also used by the interop layer.
Static ViewConfigs being a part of the new renderer [replicate](https://github.com/facebook/react-native/blob/a7586947d719a9cd2344ad346d271e7ca900de87/packages/react-native-codegen/src/generators/components/GenerateViewConfigJs.js#L164-L172) this behavior to match the old rendered.

The Android that we have is incomplete, it is missing the [*2. If it starts with `on` -> replace `on` with `top`*]. This means that some events names that worked with the old renderer would not be compatible with the new renderer + Static ViewConfigs. Specifically every event names that start with `on`.

This diff implements event name normalization on Android.

Changelog: [Internal] - Update event normalization algorithm to match SVCs.

Reviewed By: cortinico

Differential Revision: D50604571

fbshipit-source-id: cef34d8baa2cf31f641be423a16bca7ea9fa20c4

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42667

Changelog: [Internal]

Reviewed By: rubennorte

Differential Revision: D53091943

fbshipit-source-id: afbde589d2fce705f6907de929f291e7862c4258

Summary:
Cocoapods 1.15 (https://github.com/facebook/react-native/issues/42698) current breaks the build, limit to version >= 1.13 & < 1.15

This is currently broken and affecting users, we'll remove this limit once Cocopods fixes the regression.  It's currently blocking 0.73.3.

## Changelog:
[iOS][Fixed] don't allow cocoapods 1.15.

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests

Pull Request resolved: https://github.com/facebook/react-native/pull/42702

Test Plan:
```
bundle exec pod install
```

Reviewed By: cipolleschi

Differential Revision: D53180111

Pulled By: blakef

fbshipit-source-id: 4c5dd11db6d208e8d71249443a8f85e601913abd

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42682

Since D53125777, these should be safe to re-enable

Changelog:
[Internal] Re-enable dev-middleware InspectorProxy* tests

Reviewed By: huntie

Differential Revision: D53125778

fbshipit-source-id: 38911b5d6f424b46d33bb4dace18c892dc5c8c1a

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42690

Issues triggered by `InspectorProxy*` tests under `packages/dev-middleware` (T169943794) can be root-caused to `dev-middleware` performing Babel registration within a test run, after Jest has hooked its own transformer.

Babel registration is only required when running this code (`dev-middleware`, etc) directly from source - we already have the `BUILD_EXCLUDE_BABEL_REGISTER` mechanism to strip it out from production builds, but we currently don't prevent registration under tests, where Jest's transformer should be allowed to do its work.

This adds the same `babel-plugin-transform-define` mechanism that we use for production builds to the Jest transformer.

Changelog:
[Internal] Prevent inadvertent Babel registration during running of repo tests

Reviewed By: huntie

Differential Revision: D53125777

fbshipit-source-id: 1f0a20315c96edaf79054e29a80c7a9561e5b352

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42681

CI failures in Windows JS tests recently (https://github.com/facebook/react-native/pull/41463) were caused by the triggering of Babel registration during tests, due to an import of `packages/dev-middleware` (index), breaking subsequent transformation of other tests.

## Root cause
Example of a problematic import:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/dev-middleware/src/__tests__/ServerUtils.js#L15

..which triggers a Babel registration:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/dev-middleware/src/index.js#L16-L18

That registration behaves differently on Windows due to the `ignore: [/\/node_modules\/\]`, which doesn't match against Windows path separators - Babel matches against system separators.

In particular, this changed whether `node_modules/flow-parser` was transformed when loading the RN Babel transformer. Transforming this file causes a `console.warn` from Babel due to its size:
> [BABEL] Note: The code generator has deoptimised the styling of /Users/robhogan/workspace/react-native/node_modules/flow-parser/flow_parser.js as it exceeds the max of 500KB.

This throws due to our setup:
https://github.com/facebook/react-native/blob/a5d8ea4579c630af1e4e0fe1d99ad9dc0915df86/packages/react-native/jest/local-setup.js#L27

This all manifests as the first test following a Babel registration (within the same Jest worker) that requires the RN Babel transformer throwing during script transformation.

## This change
This is the minimally disruptive change that makes Babel registration behaviour consistent between Windows and other platforms. The more durable solution here would be *not* to rely on any Babel registration for Jest, which has its own `ScriptTransformer` mechanism for running code from source. Given the fragile way our internal+OSS Babel set up hangs together that's a higher-risk change, so I'll follow up separately.

Changelog: [Internal]

Reviewed By: huntie

Differential Revision: D53124578

fbshipit-source-id: 074a8e139e506a5dceec13f07d412599fb292d92

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42675

`ANDROIDLINT` config now has a base setup for RN. This enables it in arc linter, and fixes automatically fixable issues.

Changelog: [Internal]

Reviewed By: joevilches

Differential Revision: D53115471

fbshipit-source-id: 2556c21770f7c7ca54d1bccfff527d39df20101e

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42686

D53072714 accidentally removed this call, which sets the values for props which have duplicates, and some precedence between them.

This organization is janky, and will be removed in D53073913 where we decuple the props from Yoga style (so the precedence and parsing order becomes a lot more sane).

Changelog:
[Android][Fixed] - Restore missing call to `convertRawPropAliases`

Reviewed By: mdvacca

Differential Revision: D53144603

fbshipit-source-id: 85da722b23992ea75fb681f1db15e62a0daa2a51

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42685

This diff fixes the TextInput-textStyles-e2e test.
The rootcause of this issue is that we were updating the lineHeight of ReactEditText (AppCompatEditText) when lineHeight is set as a prop from React.
This is a problem, because one one side lineHeight is managed  by React Native (setting styles in the spannables) and on the other side we ar calling setLineHeight on AppCompatEditText, which breaks the rendering.

We should only manage lineHeight using RN styles, that's why I'm removing call to super.setLineHeight()

Changelog: [internal] internal

Reviewed By: NickGerleman

Differential Revision: D53142429

fbshipit-source-id: cedf803171a490afa67252e9e7f83749502326e6

introduce property on RCTPushNotificationManager to hold notification that launched the app (#42628)

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42628

Changelog: [iOS][Deprecated] Retrieving initial notification requires UNUserNotificationCenterDelegate setup instead of reading UIApplicationLaunchOptionsLocalNotificationKey

# how to migrate:

if you are currently using `getInitialNotification` to check the notification on an app start (warm or cold), you will need to do a migration.

have an object become the delegate of `UNUserNotificationCenterDelegate`. you can use your app's `AppDelegate` to do this.

then, override `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:`. in the implementation, add these lines:

  if ([response.actionIdentifier isEqualToString:UNNotificationDefaultActionIdentifier]) {
    id module = _reactHost ? [[_reactHost getModuleRegistry] moduleForName:"PushNotificationManager"]
                           : [_bridge moduleForClass:[RCTPushNotificationManager class]];

    if ([module isKindOfClass:[RCTPushNotificationManager class]]) {
      RCTPushNotificationManager *pushNotificationManager = (RCTPushNotificationManager *)module;
      pushNotificationManager.initialLocalNotification = response.notification;
    }
  }

# reasoning:

when you start an app from a push notification, the `UIApplicationLaunchOptionsLocalNotificationKey` in `application:didFinishLaunchingWithOptions:` will contain the notification metadata that started the app. additionally, this was stored on the bridge, which is not compatible with the new architecture. however, `UIApplicationLaunchOptionsLocalNotificationKey` has been deprecated since iOS 10, which this PR aims to address.

apple's supported API to do this is `userNotificationCenter:didReceiveNotificationResponse:withCompletionHandler:` which is on `UNUserNotificationCenterDelegate`. this is a significant change from a pull to push model. in order to make this change without having to rearchitect the product layer, we're going to store the notification on the notification native module.

another caveat is that the API follows the delegation pattern, not the listener pattern. that means we can't make our notificaiton native module the delegate here - the app will probably need `UNUserNotificationCenterDelegate` to be a top level object - usually the scope of the app delegate.

in future, i actually think we need to unify this with `handleLocalNotificationReceived:`, but right now there's forked handling between platforms and some product code is only using the pull model, so this is still the minimum change in the product layer.

Reviewed By: ingridwang

Differential Revision: D52897071

fbshipit-source-id: 579578d1b3128c5f7e81249c75cf7655b8e360e2

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42684

This addressed threading issue like this:

```
Attempting to set an overrideUserInterfaceStyle from a background thread. Modifying a view controller from a background thread is not supported
```

Changelog: [iOS][Fixed] Fixed potential threading issues accessing UIKit from background in RCTAlertManager

Reviewed By: philIip

Differential Revision: D52999194

fbshipit-source-id: 8ce8a89ef932ca9b75cb93d3c9f102a6b0494580

Summary:
This PR fixes the cpp crash coming from events being consumed in `dispatchModern` before forwarding it to listeners:
https://github.com/facebook/react-native/blob/ccff2bb8d19b2db244f30293b4e8d68a524c2059/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/events/FabricEventDispatcher.java#L42-L45
Because of this, all listeners that require reading from the native map (like RNReanimated using event.toString()) cause a crash since the data is no longer available - [https://github.com/facebook/react-native/blob/49f6ffc92f56953b68f340783e326145a377[…]/react-native/ReactAndroid/src/main/jni/react/jni/NativeMap.cpp](https://github.com/facebook/react-native/blob/49f6ffc92f56953b68f340783e326145a377c3b0/packages/react-native/ReactAndroid/src/main/jni/react/jni/NativeMap.cpp#L16-L19)
Restoring the previous behavior, where the event was forwarded to the listeners first, and only then dispatched further solves the problem:
https://github.com/facebook/react-native/blob/ccff2bb8d19b2db244f30293b4e8d68a524c2059/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/uimanager/events/EventDispatcherImpl.java#L116-L126
Was there a reason for changing the order here?

Or maybe there was another reason why the order was changed?

## Changelog:

[ANDROID] [FIXED] - Proper event dispatch order on Fabric

Pull Request resolved: https://github.com/facebook/react-native/pull/42664

Test Plan: Run: https://github.com/WoLewicki/NewArchStylingBug/tree/%40wolewicki/show-fabric-event-crash and try to move the square. It will cause a crash in here: https://github.com/facebook/react-native/blob/ccff2bb8d19b2db244f30293b4e8d68a524c2059/packages/react-native/ReactAndroid/src/main/java/com/facebook/react/animated/EventAnimationDriver.java#L110 when trying to read from a consumed map.

Reviewed By: sammy-SC, jessebwr

Differential Revision: D53089137

Pulled By: mdvacca

fbshipit-source-id: 8c282a417d1889732792070a404cf87acad98523

Summary:
Move all `ReactSpan` subclasses to a separate folder.

This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.

I'm adding a new span class later, which was the direct motivation for this change.

## Changelog:

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->

[INTERNAL] [CHANGE] - Move all `ReactSpan` subclasses to a separate folder

Pull Request resolved: https://github.com/facebook/react-native/pull/42594

Reviewed By: mdvacca

Differential Revision: D53123733

Pulled By: cortinico

fbshipit-source-id: 10db214a520d157c231e6f3b97948b4209a7ad4b

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42677

Changelog: [internal]

This is a re-application of https://github.com/facebook/react-native/pull/42434 which had to be reverted after a problem in a previous PR.

See details in the original PR.

Reviewed By: huntie

Differential Revision: D53122991

fbshipit-source-id: 5bc4306522fc5fa48ea81d0802d0f891706cfbf5

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42678

Changelog: [internal]

This is a re-application of https://github.com/facebook/react-native/pull/42430, which had to be reverted because of crashes in optimized builds on Android:

```
Abort Reason: terminating due to uncaught exception of type facebook::jni::JniException: java.lang.ClassNotFoundException: com.facebook.react.internal.featureflags.ReactNativeFeatureFlagsProvider
```

The root cause of that was that that class was removed because it wasn't statically referenced from Kotlin/Java, but it was dynamically referenced from C++ (in `ReactNativeFeatureFlagsProviderHolder.cpp`).

This applies the same changes + adds `DoNotStrip` annotations for the affected class and all its methods.

Reviewed By: huntie

Differential Revision: D53122992

fbshipit-source-id: efc4d5636a3f2d39b86e9c098bff408b6688b80b

Summary:
This is an implementation of UIManagerModule.findSubviewIn, based on the [Fabric renderer](https://github.com/facebook/react-fbsource-import/blob/772935f7320f37a14ef06a9616dd43fa090d54a3/compiled-rn/facebook-fbsource/xplat/js/react-native-github/Libraries/Renderer/implementations/ReactFabric-dev.fb.js#L28899-L28953).

UIManager.findSubviewIn(viewTag, point, callback)

The point is relative to viewTag's parent's (0, 0).

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D52642884

fbshipit-source-id: 775e98d23ff42d41c30644b82f5f67e788df4ee6

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42656

I'm bumping the NDK to 26.1. As we already have a bump lined up to 26.0 on main,
it makes sense to go to .1 as it's declared the LTS:
https://github.com/android/ndk/wiki

Changelog:
[Android] [Changed] - Android NDK to 26.1

Reviewed By: NickGerleman

Differential Revision: D53083606

fbshipit-source-id: 12290efcfa8a72ab88c21ffe9507d08d5512d61b

Summary:
Original commit changeset: 0ba95803f61e

Original Phabricator Diff: D52806730

bypass-github-export-checks

changelog: [internal] internal

Reviewed By: yungsters

Differential Revision: D53113947

fbshipit-source-id: ace1222a861a739fcd3f4b0e12c135db47a93344

Summary:
Original commit changeset: e30a6f2e12b4

Original Phabricator Diff: D52819137

bypass-github-export-checks

changelog: [internal] internal

Reviewed By: yungsters

Differential Revision: D53113944

fbshipit-source-id: daac6f2bf1e9cd16354987e17cb27f0bcda25f9d

Summary:
We are making some decently large changes around here, to transition Fabric away from Yoga's private API, and add new units, and CSS properties. Even confined to Fabric, we have a large matrix of different paths for parsing.

This change consolidates layout props parsing to a single, tested path, used everywhere.

Concretely, this means removing:
1. MapBuffer for ViewProps
2. Iterator style props parsing (for layout props only)

MapBuffer for ViewProps to my understanding is not currently used at all, and has been live to edits, but untested, for quite some time. Iterator style props parsing is still enabled in some configurations, but we don't want to broadly ship its current form, and haven't been able to prioritize shipping it.

Both MapBuffer, and iterator style props parser, are performance wins. If we look at seriously shipping one of these again, we should look at swapping out the current path.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D53072714

fbshipit-source-id: 0a737c8c8f50b1f2c5c0b7ff0415e84a26a06abb

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42673

Fix rendering of textInput using lineHeight in android API level <28 by removing call to ReactEditText.setLineHeight.
ReactEditText.setLineHeight was introduced in API level 28 and we actually don't need to call this method

changelog: [Internal] internal

Differential Revision: D53105649

fbshipit-source-id: f2d81cfea10de84bd47efbfeac1e21837fd49a11

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42439

UIManagerBinding's findNodeAtPoint assumes that UIManager::findNodeAtPoint returns non-null pointers. But, this is false! See [LayoutableShadowNode::findNodeAtPoint](https://github.com/facebook/react-native/blob/fd0ca4dd6209d79ac8c93dbffac2e3dca1caeadc/packages/react-native/ReactCommon/react/renderer/core/LayoutableShadowNode.cpp#L333-L354):

https://www.internalfb.com/code/fbsource/[7169da7945c813b35cd0a4fa15e66969c90c2481]/xplat/js/react-native-github/packages/react-native/ReactCommon/react/renderer/core/LayoutableShadowNode.cpp?lines=333%2C354

Changelog: [General][Fixed] Fix UIManagerBinding's findNodeAtPoint

Reviewed By: cortinico, sammy-SC

Differential Revision: D52909512

fbshipit-source-id: e1da112d4f8dcf4cdc037c978d84751eb8cf6695

Summary:
If Flow can be trusted, getConstantsForViewManager always gets called with a non-null string:
1. The only call-site to getConstantsForViewManager is getViewManagerConfig: [PaperUIManager.js](https://github.com/facebook/react-native/blob/822bf52c29729d25b2bfb31655cf773609a9283d/packages/react-native/Libraries/ReactNative/PaperUIManager.js#L36-L80)
2. And getViewManagerConfig always passes in a non-null string.

So, let's just make the native argument type a non-nullable string.

Thoughts?

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D52628937

fbshipit-source-id: 0ca68b38253cf134af29974af9e36380d66895a1

Summary:
This API was used by the old architecture to lazily register/load components:
1. Load a ViewManager's class from the disk
2. Register the ViewManager's class with React Native

See: [RCTUIManager lazilyLoadView](https://github.com/facebook/react-native/blob/822bf52c29729d25b2bfb31655cf773609a9283d/packages/react-native/React/Modules/RCTUIManager.m#L1546-L1591)

The new architecture **does not** support lazy loading of **legacy** modules/components.

Therefore, let's leave this API unimplemented until we decide to implement lazy loading of legacy stuff in new architecture.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D52677515

fbshipit-source-id: 8d49a0b54f901a3e9b3e8a9578ebb0c81de522d8

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42666

changelog: [internal]

This is shipped, let's remove gating.

Reviewed By: javache

Differential Revision: D53088420

fbshipit-source-id: ac885596da4aab7131ac7a84ff8e6655d28d6ad3

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42434

Changelog: [internal]

The flags for the event loop were set up using different mechanisms due to the limitations of the previous feature flags systems. Now we can centralize on the new system and use them consistently on Android and iOS.

Reviewed By: RSNara

Differential Revision: D52819137

fbshipit-source-id: e30a6f2e12b4a027a906502b80a70dd48bb657b6

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42430

This PR creates a new internal feature flags system for React Native. This is only meant to be used internally within the framework, but we might expose it externally in some form in the future to allow customizing specific feature flags in frameworks and applications.

Features:
* 2 types of flags:
  * Common: can be overridden from native and are accessible from all layers of the stack (Objective-C/Swift, Java/Kotlin, C++ and JavaScript).
  * JS-only: flags that can only be defined and accessed from JS (to allow things like hot reloading without a native build).
* 1 source of truth for each flag.
* Feature flags are application/process scoped (using C++ singletons).

See the `README.md` file in this PR for additional information.

This also adds modifies `run-ci-javascript-tests` to run a new check to make sure that the generate files are in sync with the JSON file that contains the definitions.

Changelog: [internal]

Reviewed By: huntie

Differential Revision: D52806730

fbshipit-source-id: 0ba95803f61ec2f05266ee535921321bf6d3dc6a

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42655

This bug is caused by a caching issue: when the user enters a new character into the textInput: ReactTextInput 1) caches the Spannable entered by the user and 2) it updates internal Fabric state, which triggers the measurement of the TextInput component using the cached Spannable.

The problem is that the Spannable entered by the user has the wrong "styles" for the text input. Since measurement is using the cached Spannable, then the measurement of the TextInput ends up being is incorrect.

In this diff I'm fixing the bug by updating the styles (lineHeight) of the cached spannable that is cached when the user updates the TextInput.
The styles weren't updated correctly because mTextAttributes didn't have the proper style props set

Changelog:
    [Android][Fixed] - Fix incorrect measurement of TextInput when new architecture is enabled

Reviewed By: javache, sammy-SC

Differential Revision: D52924982

fbshipit-source-id: ced9f2c348bdb9bf706028b1063858cebd5a071a

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42659

Those folders for Java don't exist anymore, I'm removing this as it's unnecessary and will default to only src/main/java.
For resources instead, I'm using `setSrcDirs` as it will replace the default, while `srcDirs()` will add those folders.
We need to replace the default res folder as we need to follow the resource folder structure of BUCK

Changelog:
[Internal] [Changed] - Cleanup srcSet for java and res

Reviewed By: cipolleschi

Differential Revision: D53083677

fbshipit-source-id: 4dc42c700ea5446bbd49c63fc43b58ba316f4944

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42663

changelog: [internal]

Removing the MC, this has been shipped.

Reviewed By: rubennorte

Differential Revision: D53043474

fbshipit-source-id: 2036f6752a3930666e872df0f6418e3ad8986441

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42600

Disentangled the logic for emitting touches to JS on Android. `receiveTouches` should never be used as a public API, as TouchEvents can be dispatched just like any other event, and receiveTouches is an internal helper for `TouchEvent`.

Changelog: [Android][Removed] Updated migrated guidance for EventEmitter and reduced visibility of internal TouchesHelper methods

Reviewed By: cortinico

Differential Revision: D52907393

fbshipit-source-id: a8207039c863ab23a1d93dd2d2f28e8a274c8ecf

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42660

Calling `maybeLoadSoLibrary` from init is too late, as we call `initHybrid` before `init`. Instead use a static initializer.

Changelog: [Internal]

Reviewed By: cortinico

Differential Revision: D53048065

fbshipit-source-id: dfd2957fd9209e02c498ee08e9cbd7c7a1a83c3e

Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/42657

When the RCT_DEV flag is turned on, we force the eager initialization of the DevMenu at startup.
The initialization was happening in a method of the `CxxBridgeDelegate` protocol.
In bridgeless mode, we don't have the bridge, hence we don't call this method.

I need to put the initialization code in the `RCTIntance` because the only way I found to eagerly initialize a module was to tap into the `RCTTurboModuleManager` and, in Bridgeless mode, that's seemed to be the only way.
I'm open to move the code to a better place, anyway!

## Changelog:
[Internal] - Enable the DevMenu eagerly in Bridgeless mode

Reviewed By: sammy-SC

Differential Revision: D53083637

fbshipit-source-id: 219698eab77ed115ab0f4ea43911ae883a4c9e8a

Summary:
`RCTAttributedTextUtils.mm`: Split `NSAttributedString` creation to functions in preparation for adding new logic here.

This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.

## Changelog:

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->

[INTERNAL] [CHANGE] - Refactor `NSAttributedString` creation in `RCTAttributedTextUtils.mm`

Pull Request resolved: https://github.com/facebook/react-native/pull/42595

Reviewed By: cipolleschi

Differential Revision: D53001495

Pulled By: sammy-SC

fbshipit-source-id: 52d28e48f0a9d88d44325a73c64737fc7ac97781

Summary:
Increase the readability of `CustomLineHeightSpan` by making the logic less stateful.

This is a minor improvement in the context of my multi-PR work on https://github.com/react-native-community/discussions-and-proposals/issues/695.

## Changelog:

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->

[INTERNAL] [CHANGED] - Increase the readability of `CustomLineHeightSpan`

Pull Request resolved: https://github.com/facebook/react-native/pull/42592

Test Plan:
- Prove the equivalence of the old and the new logic
- Test that the behavior of `lineHeight` doesn't change

Reviewed By: NickGerleman

Differential Revision: D53028467

Pulled By: mdvacca

fbshipit-source-id: d533bb77c8e10c29d8f2acc8cc39565d0013b03b

Summary:
Changelog: [General][Added] Enable setNativeProps in animations in the New Architecture

Pull Request resolved: https://github.com/facebook/react-native/pull/42603

Enabling setNativeProps in animations on by default.

Reviewed By: mdvacca

Differential Revision: D52962882

fbshipit-source-id: 67921c8e36e97b7b1315dfa0d5f3bd708ccb0079

Summary:
`TextLayoutUtils`: Use named arguments to ensure same-type arguments (like `start`/`end`) are not confused

This is a minor readability follow-up to https://github.com/facebook/react-native/pull/39630.

## Changelog:

<!-- Help reviewers and the release process by writing your own changelog entry.

Pick one each for the category and type tags:

[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message

For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->

[INTERNAL] [CHANGED] - Increase the `TextLayoutUtils` readability slightly

Pull Request resolved: https://github.com/facebook/react-native/pull/42593

Reviewed By: NickGerleman

Differential Revision: D53028402

Pulled By: mdvacca

fbshipit-source-id: 39e99ba70b93eecfc51bda19d30a5b1977cfe406