Do you wish to have a new codec in org.opendaylight.mdsal.binding.dom.codec.api package together with another codec

or should it have its own dom-codec-local package/bundle?

Purely local thing would be best, no sense in proliferating single-use things

So going through the analysis, we can do quite a bit of untangling, as it seem all codecs are null-hostile. The one outlier is InstanceIdentifier, which produces nulls when a YangInstanceIdentifier is not representable. Let's juggle the class hierarchy first, and let's see what possibilities fall out of this.

We have a mdsal-binding-dom-codec-api construct in BindingIdentityCodec, which pretty much follows what we want to do. There is also a counterpart in BindingInstanceIdentifierCodec, hence we should be able to generalize these constructs. Since this is an API change, move implementation to 10.0.0.