Fix up bad calls to browserify CLI after first compile

If a user migrated to my new BROWSERIFY_ARGS setting, the arguments array ended up getting extended each time this plugin got called, breaking things pretty badly 🤕

This could yield errors like this when running collectstatic:

pipeline.exceptions.CompilerError: Compiler returned non-zero exit status 1

Or inline output from browsersify during development:

Error compiling JavaScript package "my_file"
Command:

browserify --transform [ babelify --presets [ es2015 react ] --plugins [ transform-object-rest-spread transform-class-properties ] ] my_proj/collected_static_files/jsx/my_file.browserify.js --outfile my_proj/collected_static_files/jsx/my_file.browserify.browserified.js
Errors:

events.js:160
      throw er; // Unhandled 'error' event
      ^

Error: ENOENT: no such file or directory, open 'my_proj/collected_static_files/jsx/my_file.browserify.browserified.js,my_proj/collected_static_files/jsx/my_file.browserify.browserified.js.tmp-browserify-62282847839241406440'
    at Error (native)

Basically, this library would end up passing multiple --outfile arguments to browserify which it doesn't allow. This fixes so that a new list is created rather than modifying the settings one in place.

(Might be worth considering to always return a copy from _get_cmd_parts so that issues like this can't get re-introduced, but this is sufficient in the current codebase.)

Workaround without this fix is to go back to using the older BROWSERIFY_ARGUMENTS string setting.

j0hnsmith / django-pipeline-browserify

Fix up bad calls to browserify CLI after first compile #21