Summary:
Pull Request resolved: #48329

With the call to `removeView()` removed from `ReactViewClippingManager` in #47634, we're seeing views erroneously sticking around in the layout.

While `removeViewWithSubviewClippingEnabled()` calls `removeViewsInLayout()`, it does not trigger the corresponding side effects of [removeView()](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5501):
```
public void removeView(View view) {
  if (removeViewInternal(view)) {
--> requestLayout();
--> invalidate(true);
  }
}
```
To compensate, flip `removeViewsInLayout()` to [`removeViews()`](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5562), which will ensure layout.

Changelog: [Android][Fixed] Restore layout/invalidate during ReactViewClippingManager.removeViewAt()

Reviewed By: javache

Differential Revision: D67398971

fbshipit-source-id: b100db468cc3be6ddc6edd6c6d078a8a0b59a2c1

Summary:
Pull Request resolved: #48329

With the call to `removeView()` removed from `ReactViewClippingManager` in #47634, we're seeing views erroneously sticking around in the layout.

While `removeViewWithSubviewClippingEnabled()` calls `removeViewsInLayout()`, it does not trigger the corresponding side effects of [removeView()](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5501):
```
public void removeView(View view) {
  if (removeViewInternal(view)) {
--> requestLayout();
--> invalidate(true);
  }
}
```
To compensate, flip `removeViewsInLayout()` to [`removeViews()`](https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-15.0.0_r9/core/java/android/view/ViewGroup.java#5562), which will ensure layout.

Changelog: [Android][Fixed] Restore layout/invalidate during ReactViewClippingManager.removeViewAt()

Reviewed By: javache

Differential Revision: D67398971

fbshipit-source-id: b100db468cc3be6ddc6edd6c6d078a8a0b59a2c1

## Description

This PR removes the workaround introduced in series of PRs (listed
chronologically here):

1. #2307
2. #2383
3. #2495
4. #2531

For detailed description of error mechanism and broader discussion
please refer to:

1. [my comment on
#2495](#2495 (comment)),
2. [my fix to RN
core](facebook/react-native#47634)

tldr: When popping screen on Fabric we marked the views as
"transitioning" and this led to view being effectively miscounted
during removal by view groups that supported react-native's subview
clipping mechanism.

The issue has been present most likely in every version of the library
when running on Android & Fabric, but it arose few months ago due to
broader
adoption of the new architecture.

facebook/react-native#47634 is supposed to fix
the underlying issue in `react-native's` core.

## Changes

Removed the workaround code from `Screen` implementation on Android.

The 

* facebook/react-native#47634

has been released with 0.77.0-rc.3 and followup small fixup:

* facebook/react-native#48329

has been released with 0.77.0-rc.4.

Therefore, with landing this PR we should limit our support on Fabric to
0.77.0.

## Test code and steps to reproduce

`Test2282` - note that there are few testing variants available there,
you just need to comment (out) some parts of the code.

## Checklist

- [x] Included code example that can be used to test this change
- [ ] Ensured that CI passes