chore: drop React Native 0.64 - 0.67 since 3.30.0 (software-mansion#2036

)

## Description

Since React Native Screens 3.30.0, we will support only 0.68+ versions
of React Native. This PR drops support for the versions, lower than that
revision.

## Changes

- Added row to the table of supported versions in README
- Added missing bullet point for supporting visionOS
- Removed unnecessary annotation
- Removed note about bug in RN 0.61 (sadly this still occurs in newest
RN)

## Checklist

- [x] Ensured that CI passes

README.md

@@ -11,6 +11,7 @@ To learn about how to use `react-native-screens` with Fabric architecture, head
 - [x] iOS
 - [x] Android
 - [x] tvOS
+- [x] visionOS
 - [x] Windows
 - [x] Web
 
@@ -105,6 +106,7 @@ Screens are already integrated with the React Native's most popular navigation l
 
 | library version | react-native version |
 | ------- | -------------------- |
+| 3.30.0+ | 0.68.0+              |
 | 3.14.0+ | 0.64.0+              |
 | 3.0.0+  | 0.62.0+              |
 | 2.0.0+  | 0.60.0+              |
@@ -143,7 +145,7 @@ You are all set 🎉 – when screens are enabled in your application code react
 
 ### Experimental support for `react-freeze`
 
-> You have to use React Native 0.64 or higher, react-navigation 5.x or 6.x and react-native-screens >= v3.9.0
+> You have to use React Native 0.68 or higher, react-navigation 5.x or 6.x and react-native-screens >= v3.9.0
 
 Since `v3.9.0`, `react-native-screens` comes with experimental support for [`react-freeze`](https://github.com/software-mansion-labs/react-freeze). It uses the React `Suspense` mechanism to prevent parts of the React component tree from rendering, while keeping its state untouched.
 

android/src/main/java/com/swmansion/rnscreens/ScreenContainer.kt

@@ -51,16 +51,9 @@ open class ScreenContainer(context: Context?) : ViewGroup(context) {
     override fun removeView(view: View) {
         // The below block is a workaround for an issue with keyboard handling within fragments. Despite
         // Android handles input focus on the fragments that leave the screen, the keyboard stays open
-        // in a number of cases. The issue can be best reproduced on Android 5 devices, before some
-        // changes in Android's InputMethodManager have been introduced (specifically around dismissing
-        // the keyboard in onDetachedFromWindow). However, we also noticed the keyboard issue happen
-        // intermittently on recent versions of Android as well. The issue hasn't been previously
-        // noticed as in React Native <= 0.61 there was a logic that'd trigger keyboard dismiss upon a
-        // blur event (the blur even gets dispatched properly, the keyboard just stays open despite
-        // that) – note the change in RN core here:
-        // https://github.com/facebook/react-native/commit/e9b4928311513d3cbbd9d875827694eab6cfa932
+        // in a number of cases.
         // The workaround is to force-hide keyboard when the screen that has focus is dismissed (we
-        // detect that in removeView as super.removeView causes the input view to un focus while keeping
+        // detect that in removeView as super.removeView causes the input view to un-focus while keeping
         // the keyboard open).
         if (view === focusedChild) {
             (context.getSystemService(Context.INPUT_METHOD_SERVICE) as InputMethodManager)

android/src/main/java/com/swmansion/rnscreens/ScreenWindowTraits.kt

@@ -47,7 +47,6 @@ object ScreenWindowTraits {
         activity.requestedOrientation = orientation
     }
 
-    @SuppressLint("ObsoleteSdkInt") // to be removed when support for < 0.64 is dropped
     internal fun setColor(screen: Screen, activity: Activity?, context: ReactContext?) {
         if (activity == null || context == null) {
             return