ref(develop): Clarify synthetic flag in exception mechanism (#12125)

Clarifies/expands on the impact and applicability of the `synthetic` flag in the exception `mechanism`:
- adds impact on issue grouping
- adds another concrete use case when to set the flag

---------

Co-authored-by: Katie Byers <[email protected]>

develop-docs/sdk/data-model/event-payloads/exception.mdx

@@ -79,14 +79,18 @@ from the operating system or runtime APIs, as well as mechanism-specific values.
 
 `synthetic`
 
-: An optional flag indicating that this error is synthetic. Synthetic errors
-are errors that carry little meaning by themselves. This may be because they
-are created at a central place (like a crash handler), and are all
-called the same: `Error`, `Segfault` etc. When the flag is set, Sentry will then
-try to use other information (top in-app frame function) rather than exception
-type and value in the UI for the primary event display. This flag should be set
-for all "segfaults" for instance as every single error group would look very
-similar otherwise.
+: An optional flag indicating that this error is synthetic. Synthetic errors are errors that
+carry little meaning by themselves. This may be because they are created at a central
+place (like a crash handler), and are all called the same: `Error`, `Segfault` etc.
+When the flag is set, Sentry will then try to use other information (top in-app frame
+function) rather than the exception type and value in the UI for the primary event display.
+Furthermore, if this flag is set, Sentry will ignore the exception `type` when grouping the
+exception into issues.
+: This flag should be set for all "segfaults" for instance as every single error group would
+look very similar otherwise. Also, errors the SDK creates to add a stack trace to events
+that don't have one themselves should be marked as `synthetic` (This happens, for example, 
+when users set `attachStackTrace: true` and capture a string message via `captureException` 
+or `captureMessage`.)
 
 `exception_id`