fix: support multiple values after --ignore-files again

[Rob--W]

The yargs upgrade from 6.6.0 to 13.2.1 in edebef4 broke the documented ability to pass multiple files to ignore after the --ignore-files (aka -i) parameter. This is because yargs 11 started to treat requiresArg as an implicit nargs: 1, i.e. to accept exactly one value only.

There is an open upstream bug about this issue: yargs/yargs#1098
This patch works around the issue by dropping requiresArg and validating the number of parameters in the execute function instead.

Fixes #1641

[coveralls]

Coverage remained the same at 100.0% when pulling 4c60c81 on Rob--W:unbreak-multiple-ignore-files-params into 72bb28c on mozilla:master.

[rpl]

Thanks for digging into this issue @Rob--W
The fix for the --ignore-files option looks good to me.

While I was looking into the changes in this PR I also noticed that:

• it looks that --pref and --start-url are two other cli options that have changed behavior for the same underlying reason, but it seems that in the MDN docs we never suggested the syntax that has been regressed (it may still be reasonable to keep the behavior consistent across all the "array type" cli options, but not really necessary for proceeding with this PR, we can evaluate that in a follow up issue and/or PR)

• I just noticed that we never included requiresArgs: true in the definition of the --arg cli option, and so it is currently considered valid even if it being used without any parameter (as in web-ext run -a), it is not a super big deal, but still something that we should fix (this is also reasonable to be deferred to a separate PR)

[Rob--W]

Thanks for digging into this issue @Rob--W
The fix for the --ignore-files option looks good to me.

While I was looking into the changes in this PR I also noticed that:

• it looks that --pref and --start-url are two other cli options that have changed behavior for the same underlying reason, but it seems that in the MDN docs we never suggested the syntax that has been regressed (it may still be reasonable to keep the behavior consistent across all the "array type" cli options, but not really necessary for proceeding with this PR, we can evaluate that in a follow up issue and/or PR)

The old behavior was not documented, and nobody complained about it, so I guess that we're good to go with supporting one value per flag. I have no strong opinions either way, though based on the fact that it is not possible to easily support requireArgs: true, with multiple values, I am more favorable to keeping the current behavior.

• I just noticed that we never included requiresArgs: true in the definition of the --arg cli option, and so it is currently considered valid even if it being used without any parameter (as in web-ext run -a), it is not a super big deal, but still something that we should fix (this is also reasonable to be deferred to a separate PR)

Requiring a parameter for -a would be a backwards-incompatible change, and require a major version bump. Definitely something outside the scope of this patch, which aims to fix a regression from 3.0.0 -> 3.1.0.

[rpl]

@Rob--W I agree, I mentioned both because I noticed them while looking to this change but, as I said, I don't consider neither of them as blocking.