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

[pkanal]

Which problem is this PR solving?

Closes open-telemetry/opentelemetry-browser#14
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    open-telemetry/opentelemetry-js-contrib#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.

[overbalance]

1. I'm not sure what version new instrumentation should have. Do we start out with 0.0.1?
2. I don't love prefixing the name with Web but I know that is a longer conversation. Should we do that now or not? Or mark this as experimental in case we decide to remove Web/Browser prefixes as instrumentations migrates to the browser repo?

[overbalance]

You can safely delete this file.

[overbalance]

You can safely delete this file.

[overbalance]

These are now handled at the root of the repo.

Suggested change

	"lint": "eslint . --ext .ts",
	"lint:fix": "eslint . --ext .ts --fix",
	"lint:readme": "node ../../scripts/lint-readme.js",

[wolfgangcodes]

Thanks for Reviewing @overbalance

1. I'm not sure what version new instrumentation should have. Do we start out with 0.0.1?

I didn't see any guidance here. Maybe 0.1.0? I don't have strong opinions, other than it's not a 1,0, since it's still experimental to point 2 below.

2. I don't love prefixing the name with Web but I know that is a longer conversation. Should we do that now or not? Or mark this as experimental in case we decide to remove Web/Browser prefixes as instrumentations migrates to the browser repo?

I think it's experimental by default unless flagged otherwise, but we could make this explicit. I'm in favor of merging this if the implementation is acceptable and we can discuss the browser naming conventions, prefixes and disambiguation more wholistically at Browser SIG?

[overbalance]

@wolfgangcodes Agreed, we should merge first and discuss in the SIG meeting and on Slack.

[pichlermarc]

Looks good % package-lock conflicts. 🙂
Re-requesting a review from @martinkuba as it's still marked as Changes Requested