bugfix(android): fatal js errors report twice and hang 5 s

[KishanPRao]

Summary

A fatal JS error on Android now shows up once in Backtrace with its JS stack, and the app exits right after the report is sent instead of 5 s later.

Changes

• BacktraceAndroidBackgroundUnhandledExceptionHandler.java: skip React Native's rethrow of a fatal error the JS side already reported when the messages match, let the JS side release the crashing thread without the 5 s wait.
• BacktraceAndroidBackgroundUnhandledExceptionHandlerFatalErrorTest.java: new, covers a matching rethrow, one with another message, and other Java exceptions.
• UnhandledExceptionHandler.ts: send the fatal error report before handing the error to the app's handler, cap the wait at 5 s, skip or end the wait in the background and in debug builds.
• AndroidUnhandledExceptionHandler.ts: pass the reported fatal error's message to the Java handler, release the crashing thread once a rethrown error's report is stored.
• unhandledExceptionHandlerTests.spec.ts: cover the wait for the report, the 5 s cap, the background and debug build cases.
• errorHandlerSafetyTests.spec.ts: cover a failing report and a failing app handler.
• androidUnhandledExceptionHandlerTests.spec.ts: cover the message passed to the Java handler, older native modules, release builds.
• android-js-fatal.sh: new, fires a fatal JS error on the emulator, expects one stored report and an exit within 2 s of React Native's rethrow.
• ci-crash-driver.js: add a deep link that throws a fatal JS error, log each stored report.
• android.yml: run the new check after the native crash checks, keep its logcat on failure.
• build.gradle (example app): set React Native dev support per build type.
• MainApplication.java: keep dev support off in the debuggable CI release build.

Note

iOS now stays alive up to 5 s after a fatal JS error while the report uploads.

ref: BT-7804