Support configuration inheritance

[kwonoj]

This PR updates configuration parser supports 'inheritance', allow only specify env-specific config value as needed.

.compilerc now can contain common config values as well as env field as well like below example

{
  "application/javascript": {
    "presets": ["es2016-node5", "react"],
    "sourceMaps": "inline"
  },
  "text/typescript": {
    "declaration": false
  },
  "env": {
    "production": {
      "application/javascript": {
        "sourceMaps": false
      },
      "text/typescript": {
        "declaration": true,
        "jsx": "react"
      }
    },
    "development": {
      "application/javascript": {
        "plugins": ["transform-async-to-generator"]
      },
      "text/typescript": {
        "declaration": false
      }
    }
  }
}

and per environment configuration, it'll inherit default common values and override to env-specific value if it's specified.

Theoretically, this'll work not only for .compilrc but also for .babelrc - however default schema for babelrc doesn't allow those type of configuration and it falls back to dev env if env is not set, so I don't think this'll be common practice for users use their own babel configuration instead of .compilerc though.

[anaisbetts]

@kwonoj Does Babel support this syntax? I tried to keep the "env => whatever" syntax compatible

[kwonoj]

@paulcbetts as noted above, babel schema doesn't support this so it'll work as current without regression - for example,

{
"env": {
    "production": {
...
    },
    "development": {
...
    }
  }
}

will be consumed to pick up prod/dev per env. Only if anyone compose babelrc with those schema will make able to work with inheritance, but I highly doubt it since babel itself does not support it so no one will write it. These test case (https://github.com/electron/electron-compile/pull/164/files#diff-c978b3e1b35e3f56f197ecdec83270c6R253) are testing config values with current config values (without common).

[kwonoj]

If intent is make .compilerc to 100% babel compliant, this PR won't be right fit. Feel freely close PR as needed.

[kwonoj]

fyi: babel/babel#4924 there are discussion, but not concluded.

[anaisbetts]

@kwonoj Nah, I think we'll probably take this, I'll have a look tomorrow. Since it doesn't technically make us non-compliant with Babel (i.e. all existing .compilerc files are still good), it'll probably be okay