feat: make detailed errors opt-in

[G-Rath]

Summary

This aims to reduce the occurence of #10577 without solving it entirely by making what I believe to be the main source (#9496) opt-in (which we can do because this is being landed in a new major).

More specifically, it changes jest-circus to not include "detailed" errors by default unless the --detailed-errors-in-results flag is passed; including these causes circular reference errors because they're actually a JavaScript reference to whatever error that got thrown in a test - on a good day, that'll be a Jest assertion error as a result of an expect failure (which don't have any circular references), but the error can be literally anything including those thrown by ESLint in its RuleTester (which includes the AST tree which has circular references) and arbitrary objects that can include functions (which cannot be serialized).

As far as I know these detailed errors are actually only being used by JetBrains IDEs and it should be trivial for those that want to actually use them to provide the new flag to have their details included, and being able to account for the tradeoffs (namely "you might get circular reference errors").

Alternatively this could be landed with the inverse default, which'd still be useful by allowing users to explicitly have those details left out so they can see what the actual error they're getting is with the understanding that their tooling might not be as effective due to the detailed errors being missing.

Test plan

umm write some tests, probably

[netlify]

✅ Deploy Preview for jestjs ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	45ad8c0
🔍 Latest deploy log	https://app.netlify.com/sites/jestjs/deploys/66353b3fdfb9d200081aa410
😎 Deploy Preview	https://deploy-preview-15016--jestjs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[G-Rath]

@SimenB could you let me know if this is something you'd be ok to land in any form? and if so let me know how far you'd like to go i.e. do we still care about Jasmine, and do we need to have an extensive set of tests that tries to cover behaviour both with and without the flag and with and without circular references, etc?

[G-Rath]

oh and I tested this worked with eslint-plugin-jest - currently if you do yarn run test --watch when implementing a feature it errors, whereas with this it doesn't.

[G-Rath]

The "error with cause" snapshot change looks odd to me - not sure why this change would mean it no longer includes an entire error...?

[G-Rath]

Ok so it looks like in #13966 Jest might have started using failureDetails (which is the reporter side of errorsDetailed) internally (I can't test for sure as I've not been able to remember how to run specific e2e tests) - confirmed, if I change the test to pass in --detailed-errors-in-results it passes

What's interesting though is that PR is titled as adding support for causes to Jasmine whereas #13965 (which doesn't use failureDetails) was landed first adding it to snapshots - does that mean maybe circus doesn't need it...?

Either way it's an extra bit of annoyance but I still think having this flag is worth it

---

Ok I think what this is is that #13965 landed support for causes to jest-snapshot in the general sense, and then #13965 landed support for the runners actually passing the error details along