Gracefully handle unexpected or missing config value(s), perhaps provide escape hatch to handle it yourself. #127
Description
I think it'd be incredibly beneficial to long-term projects if confy didn't immediately bail if it sees unexpected or non-present fields when deserialising configs. For example, if a toml file has a field that can't be matched to a serialisable field, it'd be nice to have an option to gracefully ignore it, and only deserialise fields that are actually present.
Doubly so for configurations that have fields that are missing, BadTomlData should only really occur if a config is outright malformed. Instead, wouldn't it be more tenable to gracefully fall through to the derived Default? It's a required trait, so I see no reason not to take advantage of it here. From what I can tell, there's no way to handle this gracefully from an API consumer level.
To make a case for this, let's say I'm working on an application that needs to retain some degree of compatibility with existing config files through active development, an active userbase for example. It's a little annoying to have to require users to address the errors in their configs themselves if I decide to add or remove configuration fields.