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.

Add first batch of tests for code:clash/0.

Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>

An on_load function is supposed to return 'true' to indicate
that the module should be loaded, and 'false' if it should be
unloaded. But returning any other term, as well as causing an
exception, will also unload the module.

Since we don't like boolean values mixed with other values,
change the expected return value as follows:

* If 'ok' is returned, the module will remain loaded and become
  callable.

* If any other value is returned (or an exception is generated),
  the module will be unloaded. Also, if the returned value is
  not an atom, send a warning message to the error_logger
  (using error_logger:warning_msg/2).

The new interpretation of the return value means that an on_load
function can now directly return the return value from
erlang:load_nif/2.