Merge duplicate issues and set error grouping yourself

Three changes to how errors become issues:

• Merge issues. Select issues on the Errors page and choose Merge, then pick the one to keep. Its count and builds include the others, and their future occurrences land on it. A merged issue’s page links to where it went and has Unmerge, which hands back exactly the occurrences it brought. Merging is also available from the API and MCP.
• Set the grouping in code. Put a maple.fingerprint attribute on an error span or its exception event, and every error in that service with the same value becomes one issue, whatever its stack or message. Use a fixed name for the failure, never a per-request value.
• Grouping by your own code. When a stack has frames from your application, frames from dependencies and the runtime no longer affect the grouping. An error thrown inside a library now groups by the code of yours that called it. Existing issues carried over to the new grouping with their state, history and counts.

See How errors are grouped.