from code_SUITE:upgrade

A step toward better integration of hipe load and purge

Highlights:

* code_server no longer needs to call hipe_unified_loader:post_beam_load/1
  Instead new internal function hipe_redirect_to_module()
  is called by loading BIFs to patch native call sites if needed.

* hipe_purge_module() is called by erts_internal:purge_module/2
  to purge any native code.

* struct hipe_mfa_info redesigned and only used for exported
  functions that are called from or implemented by native code.
  A list of native call sites (struct hipe_ref) are kept for each hipe_mfa_info.

* struct hipe_sdesc used by hipe_find_mfa_from_ra()
  to build native stack traces.

The specifications for functions that load code in the 'code'
module (e.g. code:load_file/1) have some problems:

* The specs claim that the functions can return {error,on_load}, but
  they never do. However, they can return {error,on_load_failure} if
  the -on_load function in a module fails.

* The specs claim that the functions can return {error,native_code},
  but they never do.

While we are it, also extend the on_load_errors/1 test case to test
that the load functions return {error,on_load_failure} when an
-on_load function fails.

Modules in the kernel, stdlib, and compiler applications are by
default "sticky", meaning that the code server will refuse to
re-load them.

The pre-loaded modules (those that are part of the run-time system
itself, such as 'erlang') are, however, not sticky. They used to be
sticky a long time ago when the pre-loaded modules were part of
the kernel application. Now they are part of the erts application.

Since re-loading a pre-loaded module can be catastrophic (especially
re-loading the 'erlang' module), the pre-loaded modules must be
sticky. Furthermore, it should not be allowed to unstick them.

The sticky_dir/1 test case in code_SUITE is never actually run and
is broken. Rewrite it.

For now we only test beam as hipe doesn't pass the test

In embedded mode, all on_load handlers will be called after
loading all modules but before starting any servers. Therefore,
if an on_load handler calls any function in the code module that
calls the code server (such as code:priv_dir/1), there will be a
deadlock because the code server has not yet been started.

Fix this problem by invoking the on_load handlers after
having started most servers in the kernel application.