[erlang-questions] Improve $handle_undefined_function

[Fred Hebert]

As long as the call order is well-defined to always be the same
(process-defined handler -> module-defined handler), there should be no
big consistency problem.

There should be work done in order to make sure that a crash in the
`'$handle_undefined_function'` handler does *not* change the error type
from `undef` to whatever the crash was.

In my opinion, this will allow to keep a more declarative type of error
handling there while keeping the caller's expectations sane, and will
put the burden of shoddy programming maintenance on the authors of the
original handler, and not push it to the user of the library.

Let's imagine I use a module that used this feature, gets updated, and
has a bug that breaks the functionality within
`'$handle_undefined_function'`. As the user of that module, I may get
anything from `undef` to whatever the handler uses and can generate
(`badarg`, `badarith`, `badfun`, etc.). This can be *very* confusing to
debug and manage.

On the other hand, if the error is restricted to `undef`, the unknown
behaviour is pushed back on the maintainer of the library to figure out,
and inspecting the module will show that the function is indeed missing.
It breaks fewer expectations.

I would also be in favor of a new error type of the kind
`module_author_uses_features_he_or_she_is_not_understanding_please_blame_them`
to be returned to make the problem 100% obvious and embarrassing. It
could be more insulting too. I'm barely kidding here.

I'm not against the idea, but I do believe more work is needed to make
sure users of libraries are protected from bad, shoddy implementations
of the function, especially in the age-old semantics of what fails or
not.

-Fred.