This commit adds a failing test for the scenario decribed in issue
BurntSushi#425

This is a naive fix for the issue of custom unmarshal and marking
keys as "decoded". It simply assumes that if there was a custom
unmarshal for a mapping type all keys got handlded by the custom
unmarshal code.

This might be too naive but it seems reasonable and it also seems
we would need a richer interface for a custom unmarshal that gives
access to `MetaData` if we want to be more fine grained.

This commit expands the test `TestDecodeCustomStructMarkedDecoded`
so that nested data is also tested (thanks to  Martin Tournoij).

This lead to an update of the code to also mark all nested keys as
decoded when a custom `UnmarshalTOML(data any)` interface is used.

It is the job of the implemenator of the UnmarshalTOML() to ensure
everything is decoded. An alternative would be to provide a new
`UnmarshalTOMLWithMetadata(data any, md *MetaData)` inteface that
would allow the implementaor of the custom unmarshaller to mark
fields as decoded. But it's unclear if that is needed because
a UnmarshalTOML() can already error if it "sees" unexpected or
missing data.