fix: Gradle Args parsing

[breautek]

Platforms affected

Android / Gradle Argument pass through

Motivation and Context

gradle expects a specific usage which Cordova doesn't conform to.

$ gradle --help

USAGE: gradle [option...] [task...]

Currently we append the gradle arguments at the end of the gradle argument list, but option arguments are suppose to appear before the task(s).

Closes #1604

Additionally, while testing I also discovered that arguments that requires multiple values (e.g. --warning-mode all) doesn't get passed through properly, yielding an argument array that looks like:

[ "--warning-mode all" ]

when the expect array should look like:

[ "--warning-mode", "all" ]

Description

• Re-ordered the gradle argument array creation so that options appears before the task.
• Corrected tests who assumed the task will appear at index 0. Tasks will always appear at the end of the array now and have been updated accordingly with that specific expectation.
• Added a dependency to string-argv. nopt does not fit here because it expects that you know what your CLI arguments are. However since these arguments are gradle arguments, it's better if we can parse them and pass them through. This package handles quotations and such to ensure a proper argv array is created.

Testing

Ran npm test and manually tested in hello world app using commands such as:

cordova build android --minSdkVersion 30 -- --gradleArg="--stacktrace"

cordova build android --minSdkVersion 30 -- --gradleArg="--stacktrace --warning-mode all"

Checklist

• I've run the tests to see all new and existing tests pass
• I added automated test coverage as appropriate for this change
• Commit is prefixed with (platform) if this change only applies to one platform (e.g. (android))
• If this Pull Request resolves an issue, I linked to the issue in the text above (and used the correct keyword to close issues using keywords)
• I've updated the documentation if necessary

[codecov-commenter]

Codecov Report

Merging #1606 (1421eff) into master (a62f699) will increase coverage by 0.78%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##           master    #1606      +/-   ##
==========================================
+ Coverage   71.82%   72.61%   +0.78%     
==========================================
  Files          23       23              
  Lines        1796     1800       +4     
==========================================
+ Hits         1290     1307      +17     
+ Misses        506      493      -13     

Impacted Files	Coverage Δ
lib/build.js	51.45% <100.00%> (+10.86%)	⬆️
lib/builders/ProjectBuilder.js	71.87% <100.00%> (+2.25%)	⬆️

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[dpogue]

This looks okay to me.

It would maybe be good to have a test case that covered the splitting of gradleArgs into multiple extraArgs tokens.

[erisu]

Just a nitpik but, looks good to me.

[breautek]

This looks okay to me.

It would maybe be good to have a test case that covered the splitting of gradleArgs into multiple extraArgs tokens.

I added a new build.spec.js unit test file since gradle argument parsing happens earlier than what ProjectBuilder.spec.js tests. I only added testing that was relevant in the PR but could probably be expanded further to match more closely to what run.spec.js does.

Added series of different test cases regarding using the --gradleArg flag and testing the parsed argv array, which would include the usage of nopt + string-argv third-party dependencies.