Adjust dynamic.optional_field to better match documented behaviour

[michaeljones]

trafficstars

As discussed on Discord, I believe the dynamic.optional_field behaviour is a bit off and this PR tries to adjust it to match the documented behaviour.

The use of decode_optional in the implementation meant that the value was optional as well as the key which means that each use of optional_field was implicitly wrapping its value decoder in dynamic.optional.

Awkwardly this is a breaking change in behaviour but not in types. We can now get Some(None) back which I don't think was previously possible and we get an error in situations where we didn't before.

I'm not sure if the per-target tests is how you like to manage that situation.