Pass through all grunt options to protractor

[chrismikehogan]

It seems odd to have to pass in object arguments as escaped json strings.

This change allows for

1. passing in object arguments exactly as you would pass them to the protractor process.
2. overriding parts of objects via the command line, without overriding the entire object

E.g. This does not override any other capabilities or cucumberOpts you already have configured, and instead only sets these specific keys of those objects:
grunt protractor --cucumberOpts.tags=@myTag --capabilities.tunnel-identifier=myTunnelId

[teerapap]

Thanks for the PR. 👍 The fix initially looks good to me but I've tried it and found 3 issues.

1. This fix breaks backward-compatibility because some user may currently use escaped json strings to pass object argument. For this issue, I can bump the version to v4.0.0.
2. Removing grunt.options(a) for other types of arguments may also affect overridden behaviour because now it depends on how protractor handles cli argument. (I haven't tested this yet.)
3. There is a case for object type argument where its behaviour is confusing.
   I tested with grunt-cli v1.2.0 , grunt v0.4.5

configurations object is

options: {
   args: {
      params: {
          number: 1,
          bool_true: true,
      }
   }
}

and I run with command

grunt protractor --params.number=2 --params.bool_false=false --params.str="a" --params.str="b"

which populates the final protractor command with parameter

--params.number 1 --params.bool_true --params.number=2 --no-params.bool_false --params.str=b

I notice that grunt.option.flags() removes duplicated flag --params.str at this point.
and the final param object in the test are

Object({ number: [ 1, 2 ], bool_true: true, bool_false: false, str: 'b' })

To the user, params.number is not overridden like params.str but results in append in array because it is how protractor handles duplicated flags. I think this behaviour is a bit confusing.

Current behaviour is --params from command-line fully overrides options.args.params.

I'm not using this feature personally. What do you think is the expected behaviour?
and could you also add more tests related to this object argument passing?