Add `OptionalNullable<T>`?

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`, "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`, "not set" = send `null` -- I don't think it is the right approach to optionals.
3. `Nullable>`, `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`, which has methods for both `HasNonNullValue()` and `IsNull()` (and does not have `HasValue()` to avoid confusion with `Nulable`). To set null values, we add `operator=(std::nullptr_t)`/`OptionalNullable(std::nullptr_t)`.