Fix default fingerprinting when using synthetic traces

[jcruz2us]

I think I've found a bug w/ fingerprinting and synthetic traces.

When using synthetic traces via the globalOption stracktrace: true, there is an attempt to maintain the legacy grouping behavior and fingerprint on msg, not stack trace.

Looks like when this was implemented, there was a few oversights. Here is the breaking code

1. The default fingerprint is dropped and never gets to sentry
2. The fingerprint value is of the wrong type

First, there is an attempt to create a default fingerprint from the msg param passed to captureMessage. The fingerprint property is added to the options variable but the values from options are not merged back to data after the fingerprint property is set. The end-result is that fingerprint ends up getting dropped and it never makes it to sentry.

The other issue w/ the existing code is that fingerprint is set to a string value. Sentry does not like raw strings and it will ignore the fingerprint unless its an array of strings. I've modified the fingerprint value to be an array of strings.

Here is my setup and some of the JSON payloads to make things a little clearer.

Sentry 8.22.0
Raven 3.23.1
Config: {stacktrace: true}

before the fixes: (notice the ["{{ default }}"] fingerprint)

after including the fingerprint as a string: (note the fingerprint and the errors)

after including the fingerprint as an array:

[trostli]

👍

[kamilogorek]

Thanks for contributing to our lovely codebase! :)

Took your changes, made some stylistic changes and unified some code, made sure it works and merged manually to master (still as yours commit of course) - 8f8a624

Will release it next week.

Cheers! :)