feat(web-exception-instrumentation): Add instrumentation for web exceptions

[pkanal]

Which problem is this PR solving?

Currently, there's no standardized way to capture and monitor unhandled exceptions and promise rejections in web applications using OpenTelemetry. This makes it difficult for developers to:

• Track runtime errors in production applications
• Understand the frequency and types of errors occurring
• Collect detailed error information including stack traces
• Add custom attributes to error events

Short description of the changes

• Captures both synchronous errors and unhandled promise rejections
• Records error name, message, and stack trace using OpenTelemetry semantic conventions
• Supports custom attribute callback for extending error information
• Uses the OpenTelemetry Events API for lightweight error reporting
• Maintains proper cleanup of event listeners

Open questions

• This instrumentation probably shouldn't rely on the events API directly, should the instrumentation class also expose an events method like it does for tracing and logging?
• There is also a dependency on types from the api and api-logs package, is that okay or should they be redefined?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.60%. Comparing base (41d0d4b) to head (f1f5b06).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2751   +/-   ##
=======================================
  Coverage   89.60%   89.60%           
=======================================
  Files         174      174           
  Lines        8450     8450           
  Branches     1660     1660           
=======================================
  Hits         7572     7572           
  Misses        878      878           

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[MSNev]

Event names should be namespaced so just exception doesn't actually match the semantic conventions.

Please work with @Karlie-777 and her PR around defining this exception open-telemetry/semantic-conventions#1942. I agree that using the 3 top level attributes makes sense for these and I've left some comments in the link PR as well.

There are a few other properties that we should also be setting (if possible), which does mean attempting to parse out the exception on the client.

[martinkuba]

Could we be consistent with the existing semantic conventions for span events (where the event name is "exception")? Or, do we need to define exception event for each separate domain (e.g. "browser.exception", "android.exception" etc.)?

[pkanal]

I've changed it to exception for now since we're not creating any client specific semantic conventions for errors yet. We can change it in the future if this pattern develops.

[MSNev]

We should also be including the "parsed" filename as well as the current url (hosting page), I also left a comment in the related event PR that this should be part of the client exception

[MSNev]

Note: if we end up using the url.full then to comply with this PR it MUST be redacted and I don't believe that the JS repo currently has any "helpers" to construct a redacted url.full.

[MSNev]

Additional comment, while it would be "nice" to just say that the URL is in the "resources" for SPA's it really needs to be mutable which resources can't currently be 😢

[pkanal]

For now, since we're sticking with the existing semantic conventions instead of client specific ones I haven't included the parsed file name or URL. I think we can add the URL in a future PR and add some core helpers to do that separately.