Preserve the order of goals in rel file

[moiseev]

According to the systools documentation:

The applications are sorted according to the dependencies between the applications. Where there are no dependencies, the order in the .rel file is kept.

This allows a certain level of control of the application start
sequence, which, unfortunately, is not available if one is to generate
releases using relx, due to the use of an unordered container (map) to
store release app goals.

Say, you have two applications, without any dependencies between them,
that you'd like to include in the same release. The release spec would
then look like: {release, {my_release, "0.0.1"}, [b_app, a_app]}.
Expectation is that, since there are no dependencies between them, b_app
would be first in the boot script, which is not the case due to the way
maps:to_list/0 currently works.

This change adds an extra field to the parsed_goal() map, which stores
the index of the goal in the original release specification. Goals order
is then restored according to this index value prior to generating the
.rel file. No other functionality is affected.

[tsloughter]

Thanks, this was definitely a mistake on my part, the apps for a release should always stay as a list with its original order until passed to systools. I'm concerned that this got through tests... I wonder if its the sad case of tests that were meant to catch any change to this passing just by chance.

I'd prefer goals simply be a list, or goals not to be used for the call to realize/2, instead of adding an index. I thought the order would have been kept by the app_specs or applications while goals used simply as a lookup but that clearly isn't the case.

I'll dig around at some point today to see about a fix based on goals as a list or not using goals for the apps passed to realize.

[tsloughter]

Please see if #813 works for you.

[moiseev]

As long as the test passes, should be good for me. Thanks!