fix: breaking changes in raygun4android 5.2.1

[velocitysystems]

Update raygun4android to v5.2.1

Description 📝

• Purpose: Upgrade the native Android dependency from raygun4android v4.2.1 to v5.2.1, which includes the library's migration from Java to Kotlin, bug fixes, and dependency updates.
• Approach: Update all Java interop call sites in RaygunNativeBridgeModule.java to be compatible with the Kotlin-based v5 API. Since RaygunClient is now a Kotlin object (singleton), all method calls from Java must go through RaygunClient.INSTANCE. Also fix type safety issues introduced by Kotlin's explicit nullability.

Type of change

• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Updates

👉 Bumped raygun4android from 4.2.1 to 5.2.1 and raised minSdkVersion from 19 to 23 to match upstream requirements
👉 Changed all RaygunClient.xxx() calls to RaygunClient.INSTANCE.xxx() for Kotlin object interop from Java
👉 Updated RaygunUserInfo construction from new RaygunUserInfo(...) to RaygunUserInfo.create(...)
👉 Fixed setTags type mismatch — build a properly typed List<String> instead of passing ArrayList<Object>
👉 Added null guards in OnBeforeSendHandler for nullable Kotlin properties (error, message)
👉 Bumped demo kotlinVersion from 2.1.20 to 2.3.0 to match raygun4android v5.2.1's Kotlin metadata version

Screenshots 📷

N/A — no UI changes.

Test plan 🧪

• Verify Android demo project builds successfully (demo/android)
• Verify Expo demo project builds successfully (ExpoDemo/android)
• Run the demo app on an Android device/emulator and confirm:
  • Crash reporting initialises without errors
  • Sending a test crash report works
  • Setting user info works
  • Recording breadcrumbs works
  • Setting tags and custom data works
• Verify the onBeforeSend handler correctly filters out JavascriptException errors and does not crash on null values

Author to check 👓

• Project and all contained modules builds successfully
• Self-/dev-tested
• Unit/UI/Automation/Integration tests provided where applicable
• Code is written to standards
• Appropriate documentation written (code comments, internal docs)

Reviewer to check ✔️

• Project and all contained modules builds successfully
• Change has been dev-/reviewer-tested, where possible
• Unit/UI/Automation/Integration tests provided where applicable
• Code is written to standards
• Appropriate documentation written (code comments, internal docs)