Error handling, flatten, etc.

Hi. I've been trying to figure out why our program (Arti) is sometimes not printing file names in config error messages, and also trying to implement our intention to warn about ignored config fields (which I had intended to do with serde-ignored).

I have discovered that #[serde(flatten)] makes a Deserialize impl that hoovers all of the keys and values into an internal map, and then deserialises some of the individual values; and when an error occurs, throws it.

This means that errors from such structs bypass config-rs's efforts to add the appropriate key to the error. I think this situation is also responsible for the fact that serde-ignored doesn't work properly with flattening.

I have thought of two ways of getting the proper key tagging for errors (without altering serde's flatten implementation):

1. Have config-rs's MapAccess::next_value_seed wrap up the key and the Value into a struct ValueInMap, whose Deserializer impl attaches the key to each error on the way out.

2. Have a type which is a Deserializer which mutably tracks where things are in the tree, so that when a visitor returns an error, the right key can be added in deserialize_any.

I think of these, 1 is probably best. Would you welcome an MR to do that? I guess I should do a similar thing to serde-ignored.

I have also found various other issues with the error handling - in particular, that call sites that use ConfigError::custom() do not incorporate the config filename, becuase this information isn't in the relevant ConfigError variant. This is also triggered by #[serde(flatten)], which calls custom. I have been able to fix that aspect but I haven't filed an MR for it because I hadn't got the whole thing working to my satisfaction. That is itself a fairly textually intrusive MR and, unless you object, I think I will probably tidy it up and submit it, even though it doesn't make flattening work completely right.

Incidentally I also noticed #88 but I haven't seen the behaviour described there.

Thanks for your attention.

Start by reviewing config-rs's MapAccess::next_value_seed and the ConfigError::custom call sites described in the issue. Investigate how serde flatten bypasses key and filename context, then determine whether errors retain both pieces of information; done means flattened configuration errors are correctly tagged and ignored fields can be handled as intended.