ref(utils): Use type predicates for isError and isString

[lobsterkatie]

This restores part of the work done in #4124, which then got reverted in #4149. The problem there was the predicates for DOMError and DOMException, both of which only exist in a browser context. This restores the predicates for isError and isString, which should be safe, because both Error and string exist in both browser and node contexts.

[github-actions]

size-limit report

Path	Base Size (1379591)	Current Size	Change
@sentry/browser - ES5 CDN Bundle (gzipped + minified)	19.49 KB	19.49 KB	-0.02% 🔽
@sentry/browser - ES5 CDN Bundle (minified)	62.17 KB	62.17 KB	0%
@sentry/browser - ES6 CDN Bundle (gzipped + minified)	18.12 KB	18.11 KB	-0.01% 🔽
@sentry/browser - ES6 CDN Bundle (minified)	55.5 KB	55.5 KB	0%
@sentry/browser - Webpack (gzipped + minified)	22.6 KB	22.6 KB	0%
@sentry/browser - Webpack (minified)	79.21 KB	79.21 KB	0%
@sentry/react - Webpack (gzipped + minified)	22.63 KB	22.63 KB	0%
@sentry/nextjs Client - Webpack (gzipped + minified)	47.6 KB	47.6 KB	0%
@sentry/browser + @sentry/tracing - ES5 CDN Bundle (gzipped + minified)	25.37 KB	25.36 KB	-0.01% 🔽
@sentry/browser + @sentry/tracing - ES6 CDN Bundle (gzipped + minified)	23.72 KB	23.72 KB	-0.01% 🔽

[Lms24]

This LGTM and I learned about type predicates - cool feature. Are there places where we could then get rid of unnecessary casts? I just made a quick search and found this here as an example

sentry-javascript/packages/integrations/src/extraerrordata.ts

Lines 107 to 109 in 1379591

	const value = error[key];
	extraErrorInfo[key] = isError(value) ? (value as Error).toString() : value;
	}

where - if I understood type predicates correctly - we could probably get rid of as Error in the ternary operator's then branch. I tried to do it and it compiled without errors. However, it seems like eslint needs an adjustment because it highlights it as an error in (my) VSCode.

Anyway, I guess this could just as good be a separate PR for someone to pick up once we get to it.

[lobsterkatie]

No, you're totally right. If you look at the original PR, I actually went through and found all the places which could be fixed, because I was making the type predicates change for its own sake. Here I just happened upon it as part of other work and didn't follow up with the repo-wide check. I'll go port them from the other PR. Thanks for keeping me honest. 🙂

UPDATE: Found a bunch of other spots which could use the same kind of cleanup, so I'm going to merge this and throw them all into a separate PR.