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 91.32%. Comparing base (b520d04) to head (a37abc4).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2751      +/-   ##
==========================================
- Coverage   91.53%   91.32%   -0.21%     
==========================================
  Files         171      166       -5     
  Lines        8172     7861     -311     
  Branches     1660     1619      -41     
==========================================
- Hits         7480     7179     -301     
+ Misses        692      682      -10     

see 6 files with indirect coverage changes

🚀 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.

[gregorio-gerardi]

you should probably avoid Date as it is less reliable than the performance api. Check https://github.com/open-telemetry/opentelemetry-js/blob/e947bd93aed7567eff48244ada983c756a7136f1/packages/opentelemetry-core/src/common/time.ts#L48-L59

[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.

[MSNev]

We should not be including the fully qualified "named" attributes in the payload (data), they should just be passed as attributes (or if we are not using the top-level attributes then they should not be prefixed by "exception.")

[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 😢