Return None for missing Optional field attribute access

[BenjaminPelletier]

A core use case for implicitdict has always been the ability to accurately represent JSON and be easily written to JSON. In native JSON objects (and therefore in derivatives like JSON Schema and OpenAPI), the difference between absence ("this field is not present") and a positive value of null ("this field contains a value of null") is important. Therefore, implicitdict was originally developed to strongly differentiate between these two states. Specifically, if an object had an Optional foo field, then obj.foo would raise an AttributeError when obj did not have its foo key/field populated. This has caused a great deal of headache in practical usage since most (but not all) use cases, positively specifying null and omitting the field have the same effect. The headache manifests in two ways: first, it is easy to forget to check whether "foo" in obj before attempting to access obj.foo, so uss_qualifier has had a number of bugs where this checking step was omitted. Second, "foo" in obj does not link "foo" with the actual foo field definition, so searching for usages of the foo field in most IDEs will not find "foo" in obj and this is occasionally problematic.

I realized that these headaches are not necessary evils to retain the full ability to handle explicitly-null and unspecified fields, and I believe this realization will resolve all headaches without loss of functionality. By having missing Optional fields return None from their attribute accessor, we can skip the "foo" in obj check and merely check obj.foo is None in most cases. But, the ability to differentiate explicit-null from missing is still retained with the "foo" in obj check (though I expect that check to be rare in most current usage). So, I think the change in this PR is a global win, though it does change behavior enough that I think it justifies a major revision in the semantic version upon next release.

[mickmis]

Yes, that is a great improvement!