[Feature Request]: Allow more customization of how errors are handled (especially uncaughtrejection).

I've seen the suggestion here: https://github.com/qunitjs/qunit/issues/1419#issuecomment-561739486, but it seems that this is no longer viable due to properties on QUnit being read-only.

This has been the subject of extensive conversation here: https://github.com/emberjs/ember-test-helpers/issues/1128

And while I've figured out a way to test against unhandledrejection by removing QUnit's unhandledrejection event listener, it's a hack at best.
See here: https://github.com/amk221/-ember-unhappy-path-test/pull/1/files#diff-4e063cc3545f3abe7b27e539a9374abb491528a12c0810163bbe8c965b7cc066R9

I understand the philosophy is to "actually handle your rejections", but the reality is that not everyone has control over every error in their projects. Sometimes these could come from libraries / code folks can't really control -- and while in an ideal world, maybe those folks PR to the library's that they're using, but some libraries are complicated, or have a lot of history, and maintainers become afraid of accepting certain changes (this is only one such scenario!)

So, I think it would be good if QUnit exposed some utilities for (on a per-module basis), asserting that exceptions occur in certain scenarios.

Just thought I'd open an issue with some links to more context, to show what people want to do.

Start by reading the linked QUnit issue #1419 discussion and the ember-test-helpers issue #1128 for the proposed requirements and constraints. Review the referenced workaround that removes QUnit's unhandledrejection listener. Done would require an agreed per-module API for asserting or customizing exception and unhandled-rejection handling, with its scope and behavior clarified.