Take top-level config source into consideration when processing nested env/overrides.

[loganfsmyth]

Q	A
Fixed Issues?
Patch: Bug Fix?
Major: Breaking Change?
Minor: New Feature?
Tests Added + Pass?	Yes
Documentation PR Link
Any Dependency Changes?
License	MIT

I realized we had a small hole in option validation. Because we were using the config "type" field for both the type of the overall config, e.g. babelrc vs programmatic vs presets, and also env and overrides, it was possible for options to slip through that aren't supposed to be allowed, if they were inside of an env or overrides subconfig.

For example, presets don't allow ignore and only and extends, but a preset could technically have done

    {
      env: {
        test: {
          ignore: [__dirname],
        }
      }
    }

to get an ignore into the config anyway, by nesting it inside env.

This PR also improves the overall config validation logic by including more information when errors occur during validation, for example the error message for the above config will specifically call out .env["test"].ignore instead off just saying .ignore like it would have before.

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/8846/

[babel-bot]

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/8846/