Instead of having a separate panic concept which previously differed from
fatal error handling in that there was no context attached to the error,
use fatal errors also for call sites which previously used the panic handler.
Because these call sites are context-free (DUK_ASSERT() failures) simply call
the Duktape-wide default fatal error handler instead of the user fatal error
handler. For heap creation errors (self test failures) the udata is available;
for assertion it isn't and NULL is used instead.
Add a config option to replace the Duktape-wide fatal error handler; the
default one just segfaults on purpose, to avoid creating postability issues
by depending on e.g. abort().
Remove the error code from the fatal error function signature (it's mostly
pointless) and change the "ctx" argument to "udata" (heap userdata) which is
less confusing than an arbitrary context related to the heap (especially
because it's unsafe to actually use the "ctx" to e.g. call into the Duktape
API).
The fatal error signature change also affects the duk_fatal() API call, which
loses the error code argument.
* Define duk_internal_exception, a plain exception class, wihch is used as
the value thrown for Duktape internal long control transfers. The value
intentionally does not inherit from std::exception so that it'd be as
unlikely as possible that user code would catch the internal exception
type; only a "catch (...)" would catch it.
* Replace DUK_SETJMP() if clauses with "try", and SETJMP() error handling
blocks with "catch (duk_internal_exception &exc)" blocks.
* Also add clauses for "catch (std::exception &exc)" and "catch (...)" to
catch C++ exceptions thrown by user code which are propagated to Duktape
try-catch blocks. Such exceptions are converted to API errors. For now
it's not supported for user code to propagate a C++ exception "through"
Duktape, as that would require some semantics changes to (native) protected
calls. Catching and converting such exceptions to API errors makes the
user code error apparent and easier to fix.