Fix strictDecoding by only propagating not-decoded keys when decoding is successful

[stackotter]

I encountered a strictDecoding-related TOMLDecoder bug while working on Swift Bundler. If a custom Decodable implementation (init(from:)) attempts to decode with an initial strategy and then attempts a different strategy on failure, any keys not used by the initial failed (and ignored) attempt still get propagated in notDecodedKeys and end up causing decoding to throw an unused key error right at the end of the decoding process.

There were two flavours of this issue;

1. If a custom Decodable implementation somewhere in the decoding process throws an error, then its unused keys still get propagated.
2. If you create a container (e.g. a keyed container) and then realise that the value isn't in the format you expect and then create a single value container to try a different approach, the first container's unused keys still get propagated even though there wasn't any distinct point of failure in the container's eyes.

Flavour 1 was relatively easy to fix. I just updated the decode<T>(_:) method of each container type to give the inner decoder a fresh NotDecodedKeys instance and then merge the keys, but only if decoding was successful.

Flavour 2 is clearly harder to address. In my current patch I've made the assumption that whenever a container gets created from an InternalTOMLDecoder, any containers created from the decoder in the past have now been superseded. I feel like there could be some strange situation where someone might create two containers and make use of both of them to construct the final output, but I dunno if that needs to be supported, and it definitely wouldn't be as common as the 'try one thing and then try another' pattern that I was using when I discovered this issue. Let me know what you think

I've added tests for both flavours.

[stackotter]

Looks like that Windows regression is an issue with the actions runner. Doesn't seem related to anything I changed?

[LebJe]

Thanks for the PR! I think the current solution for flavor 2 is good, since, as you mentioned, someone using two containers isn't common. The Windows CI issue was fixed by updating to the Swift 6 toolchain.

[stackotter]

Ah ok good to know. The fix to Windows Swift issues does always seems to just be updating or reinstalling Swift 😅

[stackotter]

Should I fix the merge conflicts that have appeared? I should have some time tomorrow if so

[LebJe]

@stackotter sorry for the long delay! Yes please fix the merge conflicts, then I’ll merge this, add one more change, then create a release.