Handling nullable reference types

[markjamesm]

As I'm currently unsure as to which JSON responses may or may not contain null values, I'm treating all DTO class properties as nullable, and Nullable reference types are enabled project-wide as specified in the BaseballSharp .csproj file.

Treating all DTO properties as nullable means that there is a significant amount of ? (nullable) annotation throughout the code base. So far, I've only ever experienced the pitching report notes endpoint return null for a certain date.

Some proposed alternatives to this style would be:

• Skip marking the fields nullable. However, nullable reference type annotations are a feature for the code author; and even if you mark a reference field as non-nullable, this does not mean it is not null on the write.

• Alternatively, we can just accept NullReferenceExceptions if some data is unusual.

• If we want to avoid NullReferenceExceptions then we could validate all the deserialized DTOs to ensure that non-nullable fields do not actually contain null values.

I feel the cleanest option is likely option 3, to validate the DTOs after deserialization and throw when some mystery null values appear, only marking as nullable the "I expect this to sometimes be null" fields.

[markjamesm]

This has been partially resolved by using property initializers. The next step is to implement error handling as per this issue:
#16

Once the error handling is finished I will close this issue.