Allow config overrides to add new keys

[ines]

Still need to test this against spaCy to check if we need to adjust any tests here. Also a bit worried about potential unitended side-effects (or some important reason why we included this feature that I forgot).

Related: explosion/spacy-transformers#283 (comment)

---

The config system currently only allows passing on overrides for existing settings, not new keys. For instance, given a config like this:

[section]
foo = 1
bar = 2

Passing in the overrides {"section.foo": 3} is valid, whereas {"section.baz": 3} would raise an error. In a lot of scenarios, this makes sense, because you'd expect the config to be complete and describing all available settings – so anything unexpected is likely a problem. But there are other cases where the config is more flexible (e.g. a dictionary with arbitrary keys passed to a function as an argument).

[svlandeg]

I had a look into the history and apparently you had it like this in your original PR, but then changed it: ac1e9ca

There wasn't another reason discussed other than structuring the code differently.

I wonder whether it would make sense to warn when a new key is defined though. To guard the user against making a typo, accidentally adding a new key and not updating the old one as they would have expected.