feat: Support eventMapper on crashes for logs

[fuzzybinary]

What and why?

This adds a call to the configured log event mapper when a crash is reported to the Logs feature. It's tested in the integration test app by adding a fingerprint to the reported crash.

refs: RUM-2209

Review checklist

• Feature or bugfix MUST have appropriate tests (unit, integration)
• Make sure each commit and the PR mention the Issue number or JIRA reference
• Add CHANGELOG entry for user facing changes

Custom CI job configuration (optional)

• Run unit tests for Core, RUM, Trace, Logs, CR and WVT
• Run unit tests for Session Replay
• Run integration tests
• Run smoke tests
• Run tests for tools/

[datadog-datadog-prod-us1]

Datadog Report

Branch report: jward/RUM-2206-log-event-mapper
Commit report: 8d702b1
Test service: dd-sdk-ios

✅ 0 Failed, 2633 Passed, 0 Skipped, 23m 22.93s Wall Time
🔻 Test Sessions change in coverage: 6 decreased, 5 increased, 3 no change

🔻 Code Coverage Decreases vs Default Branch (6)

This report shows up to 5 code coverage decreases.

• test DatadogRUMTests tvOS 79.74% (-0.09%) - Details
• test DatadogCoreTests tvOS 79.88% (-0.06%) - Details
• test DatadogTraceTests tvOS 49.71% (-0.03%) - Details
• test DatadogLogsTests tvOS 45.97% (-0.01%) - Details
• test DatadogLogsTests iOS 45.92% (-0.01%) - Details

[maxep]

Looks good 👍 would be convenient to default the mapper to nil in the crash receiver, WDYT?

[maxep]

/siggestion For convenience, we can have an init that default the mapper to nil

[fuzzybinary]

Since this in internal, I thought it would be good to enforce adding it / explicitly setting it to nil. I can add the default if you disagree.

[ncreated]

I also prefer being explicit. This way compiler will guide us on all the places where MessageReceiver is used and will make us think of injecting mapper where it makes sense. If we seek for testing convenience, it is safer to add it through extension in test module.

[ncreated]

👍 Looks good, but please add CHANGELOG entry 🙂