Provide a non-null type constraint for better interop with swift

Due to constraints related to how obj-c and swift handle nullable types, generic type parameters from kotlin get converted into nullable types unless they have a non-null constraint:

Reaktive suffers from the same problem: its value callbacks receive a nullable types:

Will it be possible to make this change in ValueCallback?

interface ValueCallback<in T : Any> {

[arkivanov]

Working on this currently. I still think that one non-null ObservableWrapper<out T : Any> will be better than two nullable and non-null. My points:

1. Nullable cases are rare, we mostly use non-null types (we also have Maybe that helps a lot)
2. If a user needs additional operators e.g. map they can extend just one class ObservableWrapper and add whatever needed. If there are two classes then the complexity may grow up to 4 times.
3. If there is a strong need to expose non-null types to Swift then something like a simple Optional may be used instead
4. We could provide overloaded subscribe methods only for one class instead of two

Overall I believe it is better to have solid and non-confusing API for most of the cases.

@mk-jones @CherryPerry @saket Waiting for your opinions!

[mike-n-jordan]

@arkivanov Perhaps something like a NonNullObservableWrapper<T: Any>? So the user can choose how we communicate the type to swift.