Rework error handling

[bettio]

This is likely a wrong pattern:

  70 #define RAISE(a, b)  \
  71     ctx->x[0] = (a); \
  72     ctx->x[1] = (b); \
  73     return term_invalid_term();

We should store relevant information as part of Context, so they don't get clobbered by mistake.

I think this kind of workaround, that @mat-hek did, explains pretty well the issue (I think) we have:

static bool is_exception_class(term t)
{
    return t == ERROR_ATOM || t == LOWERCASE_EXIT_ATOM || t == THROW_ATOM;
}
[...]
if (stacktrace_is_built(stacktrace)) {
    //  FIXME: This is a temporary solution as in some niche cases of reraise the x_regs[0] is
    //  overwritten and it does not represent exception class
    if (!is_exception_class(x_regs[0])) {
        x_regs[0] = ERROR_ATOM;
    }

2. Any drawback of adding additional fields to Context?

I think we should be able to manage this adding to Context something like:

context_flags_t flags; // error, exit, throw, ... (space for more flags)
term reason;
term stacktrace;

In the future we might even add:

term value;

This can be set from VALIDATE_VALUE macro for improved debugging.
Also avoiding overwriting x[0]...x[2] registers, allows us to have improved stacktraces, than can contain function arguments and so on.

Originally posted by @bettio in #1804 (comment)

[UncleGrumpy]

Any improvements to error handling and stacktraces would be fantastic. While this work is being undertaken we should consider a mechanism for selectively suppressing stacktraces for specific modules. The specific case I have in mind is the supervisor module. OTP does not log stacktraces for supervised children, instead the supervisor uses logger to display nicely formatted error reports and crash reports when a child crashes, and supervisor reports for when the supervisor encounters a problem.

[mat-hek]

While this work is being undertaken we should consider a mechanism for selectively suppressing stacktraces for specific modules

This is kind of another story, since it's about what prints the stacktraces, and this issue is about how the stacktraces are generated. However, it's already possible to suppress process crash dumps (if that's what you mean) totally, see https://github.com/atomvm/AtomVM/pull/1799/files. IMO they should eventually be disabled by default and logger should be used for printing errors, like in OTP.