* nox/filelib-wildcard-broken-link:
  Update stdlib appup file
  Update runtime dependencies
  Update preloaded
  Add tests of filelib and symlinks
  Fix handling of broken symlinks in filelib

Conflicts:
	erts/preloaded/ebin/erl_prim_loader.beam

This fixes a bug introduced in f11aabdc9fec593c31e6c4f3fa25c1707e9c35df where
filelib:eval_read_file_info/2 was made to use file:read_link_info/1 to never
follow symlinks. This fixed wildcard/1 but broke every other function using
eval_read_file_info/2.

Reported-by: Louis-Philippe Gauthier
Reported-by: Danil Zagoskin

* bjorn/kernel/remove-file_info-vestiges/OTP-11982:
  Remove documentation and stub for non-exist file:file_info/1

file:file_info/1 was removed a long time ago, but its
documentation was not removed.

Commit ed06dd12ea74018b902a2c4c7924313d23cedb75 made pre-loaded
modules (such as erlang) sticky, and also made it impossible to
unstick them to prevent them from ever be reloaded.

It turns out that there are tools that may want to instrument
the erlang module (such as concuerror), so making it
impossible to unstick modules is harsh. Therefore, revert the
part of the commit that prevented unsticking the pre-loaded
modules.

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.

The following sequence will NOT leave the code path unchanged:

  code:add_path("/some/app/"),
  .
  .
  .
  code:del_path("/some/app/")

The reason is that code:add_path/1 will normalize the path name
(removing the trailing slash), while code:del_path/1 does not
normalize the path before searching for it in the code path.

If the Config given to application_controller:change_application_data
included other config files, it was only expanded for already existing
(loaded) applications. If an upgrade added a new application which had
config data in an included config file, the new application did not
get correct config data.

This is now changed so config data will be expanded for all
applications.