[reltool] Add test of dependencies derived through calls to external apps

OTP-9794

This is a test of the mechanism with which reltool_server decides
which applications to include and not, based on function calls between
applications. This is also the mechanism which forms the base for the
application- and module dependency graphs.
[reltool] Ensure that tests do not try to start node if target was not created

OTP-9794

Some test cases in reltool_server_SUITE tried to create a target
system and then start a node running this system. If creation of the
target system failed, an attempt would still be made to start the
node. This has been corrected so the test is immediately terminated if
the target system could not be created.
[reltool] Add test case for reltool_server:get_mod

OTP-9794

This test case revealed a bug that occurs when calling
reltool_server:get_mod after reltool_server:undo_config. get_mod reads
from the module table (ets) and not from the reltool_server state,
while undo_config only changes the state. This bug has been corrected,
so undo_config now updates both state and tables (it does the same as
set_sys).
[reltool] Add more tests

OTP-9794

Test cases are added for the following functions:
* reltool_server:get_sys
* reltool_server:set_sys
* reltool_server:get_status
* reltool_server:gen_rel_files
* reltool:eval_target_spec
* reltool:get_server
[reltool] Add more GUI tests

OTP-9794

This commit adds a test suite for manual testing of the reltool
GUI. By use of test_server:break/1 function, it guides the user
through a set of tests in the GUI.

Some minor checks are also added to the automatic GUI test,
reltool_wx_SUITE.
[reltool] Add tests for sorting of applications in .rel and .script files

OTP-9794

Test cases create_release_sort and create_script_sort are added. The
test are temporarily skipped since they detected quite a few bugs that
will be corrected with OTP-9792.

The following bug is corrected in this commit:'
reltool_server did not recognize {App,InclApps} inside a 'rel'
specification in the reltool config, e.g.
{rel, "myrel", "1.0", [{myapp,[app2]}]}.
[reltool] Add test cases for handling of escripts

OTP-9794
OTP-9968

The following test cases are added:
* create_standalone_beam
* create_standalone_app
* create_multiple_standalone
* load_config_escript_path
* load_config_same_escript_source
* load_config_same_escript_beam
* load_config_add_escript

Most of them are temporarily skipped since they re-produce known
problems that will be corrected in a later commit.
[reltool] Update state and tables consistently for all types of config changes

OTP-9794
OTP-9968

The main idea behind the data structure in reltool_server is that the
state shall reflect what is explicitly configured, and the tables
shall contain this configuration plus everything that is derived. In
some cases, however, this was not the complete truth:

* the application table was never read
* the module table was never updated on undo
* the state contained a lot more than what was explicitly configured

This commit re-writes major parts of the reltool_server for the sake
of unifying the way the state and tables are updated:

* The list of applications in the state now only contains those
  applications and modules for which there are explicit settings in
  the configuration (given at startup or changed from the GUI)

* When changing any bit of the configuration, the tables are always
  emptied and every part is derived again from the configuration found
  in the state

* All configuration changes now cause a re-read of the file system,
  meaning that if something has changed in the file system it will be
  reflected in the result of the configuration change. This is the
  case even if no file system related configuration is changed
  (e.g. root dir or lib dirs)
  (*POSSIBLE INCOMPATIBILITY*)

* Requests for applications and modules from the GUI now always read
  the tables, not the state

* When loading a new configuration file via the GUI, the old
  configuration is completly scratched, and only the new is valid
  (*POSSIBLE INCOMPATIBILITY*)

* The handling of escripts which include archives of applications is
  changed to always produce one #app record for the escript in
  addition to one for each inlined application. All modules are listed
  as parts of the inlined application where it belongs and not as part
  of the escript's #app record. This is a temporary solution which
  will be modified and improved.

The following bugs are corrected by this commit:

* Loading a config which contains an escript via the GUI menu did not
  produce the same #app record as when loading the same configuration
  at reltool start. Paths, version and label could differ.

* Loading config with same escript (source) twice caused reltool to
  add same module twice in #app.mods

* Loading config with same escript (inlined beam) twice caused reltool
  to fail saying module is included by two different applications

* Loading config which in addition to an existing escript also adds
  another escript for which the name sorts before the existing one
  would cause reltool to fail saying "Application name clash"
[reltool] Fix badmatch when starting GUI

OTP-9792

Start of reltool GUI sometimes crashes with a badmatch in
reltool_sys_win:do_init/1 because the #sys record fetched with
reltool_server:get_sys/1 differs from the #sys record returned from
reltool_server:start_link/1. This has been
corrected. reltool_server:start_link/1 no longer retuns the #sys
record.
[reltool] Link together escript with inlined application

OTP-9968

Make sure that inlined applications in an escript is included/excluded
as the escript itself, and forbid explicit configuration of the
inlined application.
[reltool] Fix rollback and undo

OTP-9794

Backup old configuration before starting re-configuration so rollback
is possible if configuration fails.

Store last configuration including derivates so undo does no longer
need to refresh and analyse everything from disk.
[reltool] Improve error handling

OTP-9794

Stopping configuration (throw/catch) at first error instead of
continuing through all steps and then returning the error at the
end.

Start of reltool_server will no longer succeed if the configuration
causes an error.

reltool:get_status can only return {error,Reason} in the case where
the reltool_server has terminated. In all other cases it will return
{ok,Warnings}.

Bug fix in this commit:
* warnings are no longer duplicated in pop-up or return from reltool_server
[reltool] Unset ERL_FLAGS when running escript from reltool_server_SUITE

OTP-9794

Some escript tests in reltool_server_SUITE failed if ERL_FLAGS was set
to enable smp. The reason is that the test expected smp_support to be
false, since the argument "-smp disable" is stated in the %%!-line of
the escript. However, ERL_FLAGS will override the arguments in the
escript so the result could not be truested.
[reltool] Cleanup test code

OTP-9794

Remove some unused code from reltool test.
[reltool] Display warnings continously in GUI

OTP-9967

All active warnings are now displayed in a specific warning list at
the bottom of the sys windows. Warnings do no longer cause popup
dialogs during configuration.

The reason for this is to avoid the same warning to pop up many
times. This would happen since each configuration change now causes a
fresh reading of the file system - and thus each warning would be
detected each time the configuration was changed.

reltool_manual_gui_SUITE is updated to test the new functionality.
[reltool] Move tables out of common record

OTP-9794

This is a minor change, in order to keep tables private to
reltool_server.
[reltool] Fix type spec and doc for app() and mod()

OTP-9792

Also correct documentation of reltool:install/2: first argument is
RelName, not Server.
[reltool] Always return warnings as flat strings

OTP-9794
[reltool] Just warn if same module occurs twice in .app file

OTP-9792

Earlier this would cause an error with reason
"Module xxx potentially included by two different applications: yyy and yyy."

This is now changed so it will only be a warning saying that the
module is duplicated in the .app file.
[reltool] Fix problems with sorting of applications

OTP-9792

The following problems have been solved:

* reltool_target:do_merge_apps - in recursive calls to this function,
  the accumulator was reverted each time causing the order of
  applications listed after kernel and stdlib in the rel specification
  in the configuration to sometimes be messed up.

* There are several ways to specify wich applications to include in an
  application:
  1) in the .app file for the including applications
  2a) in the .rel file, when listing applications
  2b) in the rel specification in the reltool configuration

  2a (systools) and 2b (reltool) should have the same effect and
  overwrite 1.

  According to the documentation of systools (sasl), the default value
  in 2a is an empty list. This should mean that if included
  applications are not mentioned in the .rel file, then any included
  application listed in the .app file will be disregarded. This is NOT
  the way systools actually works. The implementation sets the default
  for the .rel file to the same list as in the .app file.

  Reltool earlier implemented 2b as described in the systools
  documentation. However, after some discussion we decided to change
  this so that reltool handles 2b in the same way as systools handles
  2a since this seems more intuitive. The sasl documentation will be
  altered accordingly (internal ref OTP-9980).

* If the rel specification in the reltool configuration explicitly
  specified included applications to be an empty list, and the .app
  file had a non-empty list, then the empty list from the rel
  specification was discarded. This has been corrected so the rel
  specification now, if set, always overwrites the value of
  included_applications in the .app file.

* reltool would earlier add load instructions in the script/boot files
  for ALL modules in the ebin directory of an application even if
  mod_cond was set to app (include only modules listed in the .app
  file). This has been corrected - now only modules with
  #mod.is_included==true are loaded.

* reltool would earlier add start instructions in the script/boot file
  for included applications. This has been corrected - included
  applications shall only be loaded since the including application is
  responsible for starting them.