Add OptionalNullable<T>?

[antkmsft]

Non-nullable optionals should be Nullable<> - to distinguish between "not set" vs "" (strings) / 0 (ints), [] (arrays).
That distinction allows customer to express any value, without sacrificing anything. When !HasValue(), we don't send the value.

With non-optional nullables, everything is also Nullable<>, the only difference is that when nullable has no value, we serialize it as null (at least, in JSON body context; I don't remember exactly how paths/query params/headers behave - that's ok, that's beyond the point).

And finally, if there is an optional nullable, then we have two options:

1. Nullable<T>, "not set" = do not send, "has value" = send value. This won't allow users to send null values, but maybe it is practical enough.
2. Nullable<T>, "not set" = send null -- I don't think it is the right approach to optionals.
3. Nullable<Nullable<T>>, options.Property.HasValue() == false = do not send, options.Property.HasValue() == true && options.Property.Value().HasValue() == false = send null; options.Property.HasValue() == true && options.Property.Value().HasValue() == true = send options.Value().Value(). This would be an implementation that allows to accurately represent any value, but it is most likely too complex to be used by humans. I think we should implement option 1, and if we ever encounter a need for the service to distinguish between null and lack of value sent in this case, we work with the service team, or we should put some other solution (i.e. something like item 4 below).
4. Develop something like OptionalNullable<T>, which has methods for both HasNonNullValue() and IsNull() (and does not have HasValue() to avoid confusion with Nulable<T>). To set null values, we add operator=(std::nullptr_t)/OptionalNullable<T>(std::nullptr_t).