[Enchancement] Filter unknown options to the rebar command and warn profile ignore

[sanzor]

So i was using this command : rebar3 release as [Profile] -o OutputFolder

and little did i know that in this format the Profile will get ignored , thus my configuration file set up in rebar.config for this specific profile will get ignored and a default one will be put in place with the value of [ ].

I did not know the correct format was this :

rebar3 as [Profile] release -o OutputFolder

Could we do something to let the user know that command is invalid or some of the options got ignored ? (in my case the profile)

I did not know it got ignored and a whole bunch of related problems depending on that profile occured.

Current behaviour

Profile will get ignored and if there is a {sys_config_src,[Path]} configured for it, a default sys.config file will get generated with the value of [ ]. This will occur without warning , and you as a user will not know what config you are using.

Expected behaviour

So i guess the problem here is twofold:

1. Somehow let the user know that the format of the command is invalid or some of the options will get ignored
2. Let the user know that if the profile was ignored , and with it , the associated config file , the release is using a default one with the value [ ]

[ferd]

As for scoping: this is a result of an interaction with the getopt library we use and possibly not being very strict with how we call it:

4> OptSpecList =
4>     [
4>      {define,  $D, "define",  string,  "Define a variable"},
4>      {verbose, $v, "verbose", integer, "Verbosity level"}
4>     ].
[{define,68,"define",string,"Define a variable"},
 {verbose,118,"verbose",integer,"Verbosity level"}]
6> getopt:parse(OptSpecList, "as whatever -DFOO -DVAR1=VAL1 -DBAR --verbose --verbose=3 -v -vvvv dummy").
{ok,{[{define,"FOO"},
      {define,"VAR1=VAL1"},
      {define,"BAR"},
      {verbose,1},
      {verbose,3},
      {verbose,1},
      {verbose,4}],
     ["as","whatever","dummy"]}}

Chances are we're just dropping the extra terms at the end silently rather than erroring out on them. This will require patching in each provider/command.