escript: Handle symbolic link to a standalone escript

[hawk]

The code has been rearranged to make use of the actual path
"get_default_emulator(scriptname)" to the escript instead of
the given one "get_default_emulator(argv[0])".

TL;DR

Assume a source system with some Erlang applications (app1, app2 etc.)
and an escript called "mytool". When generating a standalone target
system (with reltool for example), the escript(s) are located in the
same top bin directory as "erl". See mytool* below.

In such a system the original "mytool" escript is given the extension
".escript" and the file with the same name as the original escript is
a copy of the "escript" executable. One purpose of the escript
executable is to determine which "erl" to use to start the system.

In a standalone system we want it to find the runtime system bundled
with the escript(s). This is done by analyzing the path in order to
find the "erl" located in the same directory as the escript.

A dilemma here is that we do not want to put the top bin directory
in the execution path (PATH env var) as we then would cause other
Erlang applications to make use of our bundled run-time system.

One way of solving this is to choose some suitable bin directory in
the execution path (such as /user/local/bin) and put a symbolic link
there to our mytool executable.

Unfortunately this did not work as the escript executable (in this
case called mytool) would try to find "erl" in /usr/local/bin and when
it did not find such a file it resorted to use the command "erl" which
would find some (unwanted) "erl" in the execution path.

My fix solves that problem.

├── bin/
│   ├── erl* (dyn_erl.c)
│   ├── mytool* (escript.c)
│   ├── mytool.escript* (original mytool escript)
│   └── start_clean.boot
├── erts-vsn/
│   └── bin/
│   ├── beam*
│   ├── beam.smp*
│   ├── erl*
│   ├── erl_child_setup*
│   ├── erlexec*
│   └── inet_gethost*
└── lib/
├── app1-vsn
├── app2-vsn
└── ...

[hawk]

It is a little tricky to do a test case for this as it involves fiddling with the PATH env var. Further I assume that you do not want test cases for erts to be dependent of the reltool app. How do you want me to proceed with the test case?

[hawk]

Ping.

[rickard-green]

Pong :-)

I've merged this PR into the master branch. We don't want to merge it into the maint branch since it changes the behavior.

[hawk]

Coolers. Thanks.