Updates needed to support v3.0.1 (and future patches)

[PerthCharern]

1. I did a diff from 3.0.0 to 3.0.1 and didn't see changes to the model itself, so there shouldn't be any major deserialization/serialization needed in this library.
2. Recognize 3.0.1 in the openapi field in the OpenAPI Object. It can still use all the existing V3 deserialization logic.
3. Create new enum value OpenApi3_0_1. (I'm going back and forth about this. This last number is simply a patch to the spec. Should we support enum for every single patch explicitly, or should we always try to output the latest patch for a given Major.Minor)

[darrelmiller]

It should be rare that we need to make a change for a patch release. It might be worth updating the output version number once we have review the patch and determined that we are still compatible.
I don't think we need to enumerate patch versions. The plan is to release a patch at the beginning of each month incorporating corrections that were incorporated in the previous month. We don't want to have to update for each of those :-)

[PerthCharern]

If we only write the latest patch number, I wonder if our customers would face issue with other tools that may not be updated as often. (Say we output the version string "3.0.1" now, but some tools may still recognize only "3.0.0")

I understand that ideally tools are supposed to support the latest patch, but I'm not sure how reality would hold up.