Stacktraces are only generated for the first 50 "throw" usage in a rea...

Seen while working on Bug 1770754, we stop getting stacktraces after 50 errors have been thrown on a specific window global. This only impacts stacktraces which are normally not observable from JS code, ie uncaught exceptions using throw.

So in practice, executing a script.evaluate command with an expression which throws (eg a.b.c.d with a not defined in the current global), will correctly have a stacktrace even when executed more than 50 times. But with an expression which uses the throw keyword (eg throw new Error()) the stacktrace will be missing after 50 executions.

This comes from the following logic:
https://searchfox.org/mozilla-central/rev/b1e5f2c7c96be36974262551978d54f457db2cae/js/src/vm/Realm.cpp#589-606

If the realm is a debuggee, the restriction is lifted so that errors can be inspected if the console is opened.

The first question is if we should force the same behavior for Realms monitored by BiDi, or consider that the stacktrace is optional and is implementation specific.

If we decide that we always want the stacktrace for BiDi monitored Realm, we can either add a dedicated API (similar as to what was done for async stacktraces in Bug 1775207, maybe modifying and reusing that?) or switch from makeGlobalObjectReference to addDebuggee.

Given that we want BiDi to offer debugging features in the long run, we will probably need the same features as for devtools, so I'm not sure if we will be able to avoid using addDebuggee forever. We might want to look at the performance impact of doing that in more details.