Merge target config with common config

[Szymon Nowak]

I've got the following configuration:

    ngconstant: {
      options: {
        space: '  '
      },
      development: [{
        dest: '<%= yeoman.app %>/scripts/env-config.js',
        wrap: '"use strict";\n\n <%= __ngModule %>',
        name: 'envConfig',
        constants: grunt.file.readJSON("config/development.json")
      }],
      staging: [{
        dest: '<%= yeoman.app %>/scripts/env-config.js',
        wrap: '"use strict";\n\n <%= __ngModule %>',
        name: 'envConfig',
        constants: grunt.file.readJSON("config/staging.json")
      }],
      production: [{
        dest: '<%= yeoman.app %>/scripts/env-config.js',
        wrap: '"use strict";\n\n <%= __ngModule %>',
        name: 'envConfig',
        constants: grunt.file.readJSON("config/production.json")
      }]
    }

The first 3 options are the same for all targets, however, moving them up to common config doesn't set them on target configs.

[Malte Legenhausen]

wrap should work but the other options can not be set as global parameters. This can be related to #12.

[Szymon Nowak]

@mlegenhausen There's also an other issue when using "multiple module option" - it breaks running grunt with --verbose option. It's probably the same issue as iammerrick/grunt-parallel#11.

I'm not sure though how the configuration should look like to handle single and multiple modules together with the default task/target options. In theory in case of multiple modules there could be the default options for the task, the default options for the target and then options for specific module.

Maybe just skip single module option and do sth like this:

ngconstant: {
  options: { 
    // task defaults 
  },
  development: {
    options: { 
      // target defaults 
    },
    modules: [{
      // module options
    }]
  }
}

No idea how other tasks handle similar configuration.

[Malte Legenhausen]

I think it is not intended to remove all redundant information from a configuration that can happen. Instead we should find a trade-off.

Currently I would think that dest, name and constants can be redundant, cause it can be common to have several dest paths for several environments. The name doesn't fit for me in the options and should be used a identifier for multi constants definition (currently I merge by index instead by name, maybe I add this feature) and the constants are normally always different between different environments.

I like your idea with the modules parameter.

We should continue the discussion in #12. It would be nice if you can give me an example how your configuration should look like.