Remove old implementation of Crashes

[priettt]

• Removed EmbraceCrashService.

This was the legacy way of handling crashes for Embrace. We now use CrashDataSource, which will add the crashes to the current session span and emit an OTel log.

• Removed CompositeCrashService

This allowed us to use the legacy or the new crashes implementation, depending on a config flag (configService.oTelBehavior.isBetaEnabled()).
Most importantly, it registered the EmbraceUncaughtExceptionHandler when the class was initialized. This was moved to the CrashDataSourceImpl.

Questions:

• Should we remove the LegacyException[Info/Error/ErrorInfo] classes? They are used in the new implementation, so I'm not sure how.
• Should we still use the CrashService interface? Should we replace it with CrashDataSource?

[codecov]

Codecov Report

Attention: Patch coverage is 75.00000% with 2 lines in your changes missing coverage. Please review.

Project coverage is 80.10%. Comparing base (aa671ec) to head (070436d).

Additional details and impacted files

@@                     Coverage Diff                      @@
##           integration/v2-migration     #921      +/-   ##
============================================================
- Coverage                     80.23%   80.10%   -0.14%     
============================================================
  Files                           443      440       -3     
  Lines                         11560    11458     -102     
  Branches                       1791     1783       -8     
============================================================
- Hits                           9275     9178      -97     
- Misses                         1480     1481       +1     
+ Partials                        805      799       -6     

Files	Coverage Δ
...mbrace/android/embracesdk/injection/CrashModule.kt	100.00% <100.00%> (+27.11%)	⬆️
...oid/embracesdk/injection/ModuleInitBootstrapper.kt	92.64% <ø> (-0.06%)	⬇️
...id/embracesdk/capture/crash/CrashDataSourceImpl.kt	89.39% <71.42%> (-2.14%)	⬇️

... and 7 files with indirect coverage changes

[fractalwrench]

LGTM, but it'd probably be sensible to target this at integration/v2-migration unless you've already verified that this works fine E2E and are happy to ship this to production.

For classes like LegacyExceptionInfo etc, we could remove the serialization annotations & rename the class. It'd be preferable to do that in another changeset though