feat(core): Add ignoreSentryInternalFrames option to thirdPartyErrorFilterIntegration

[chargome]

Some users get flooded by third party errors despite having set their third party error filtering to "drop-error-if-contains-third-party-frames". This comes from the fact that often the stacktrace includes our internal wrapper logic as last trace in the stack.

With this PR we're trying to work around this by specifically ignoring these frames with a new opt-in mechanism. Marked this as experimental, so users will know this option might lead to errors being misclassified.

• Adds a new experimental option experimentalExcludeSentryInternalFrames to the thirdPartyErrorFilterIntegration
• Once enabled we apply a strict filter for frames to detect our internal wrapping logic and filter them out so they do not misclassify injected code as internal errors.

Closes #13835

[linear]

JS-114 `thirdPartyErrorFilterIntegration` does not filter errors correctly

[github-actions]

node-overhead report 🧳

Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.

Scenario	Requests/s	% of Baseline	Prev. Requests/s	Change %
GET Baseline	9,278	-	9,247	+0%
GET With Sentry	1,775	19%	1,801	-1%
GET With Sentry (error only)	6,227	67%	6,311	-1%
POST Baseline	1,204	-	1,237	-3%
POST With Sentry	606	50%	605	+0%
POST With Sentry (error only)	1,058	88%	1,077	-2%
MYSQL Baseline	3,330	-	3,428	-3%
MYSQL With Sentry	510	15%	524	-3%
MYSQL With Sentry (error only)	2,687	81%	2,767	-3%

View base workflow run

[Lms24]

It makes sense to not alter existing behaviour in the major but if this proves to be valuable, perhaps it should become default behaviour in the next major?

[chargome]

I renamed the option to exclude the experimental prefix, we'll leave this undocumented for now and if users find this valuable we can make this the default behaviour in v11