Make Android ViewObservable.input observe TextView instead of String

The previous version required `ViewObservable.input(TextView, boolean)` to emit just `String`s of the updated text, but not `CharSequence`s, which is the declared implementation of `TextView`'s `mText`. This still allows for similar functionality as before via: 

```java
ViewObservable.input(myTextView, false).map((textView) -> textView.getText().toString())
```

It is also flexible like `ViewObservable.clicks` in that it returns a reference to the `View`, which should make it more flexible for using it with other reactive methods.

I held off from doing the same to `ViewObservable.input(CompoundButton, boolean)` but could do so if you think it would be valuable/more consistent.

This would be a breaking change. In order to make it not a breaking change, this method could be renamed and the initial method could `map` like the above snippet. Let me know if you think this is important and I'd be happy to make this change.
It depends on where in the chain this operator is lifted. If after `observeOn` then this code is needed, if before then I don't think it is needed.

There was a very lengthy discussion with @zsxwing at one point about this and it appeared there could be some extreme edge cases that could occur so I think this was done here to conservatively protect against that.

`observeOn` does schedule the `unsubscribe`: https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/main/java/rx/internal/operators/OperatorObserveOn.java#L223 However, that is scheduling the `unsubscribe` for this use case: https://github.com/Netflix/RxJava/blob/master/rxjava-core/src/test/java/rx/internal/operators/OperatorObserveOnTest.java#L374 and it affects the "upstream", not "downstream" where I believe this operator will exist.

Thus, if `OperatorTextView` is below the `observeOn` operator and registering an `unsubscribe` it is outside the control of `observeOn`. That means it needs to schedule the behavior of `input.removeTextChangedListener` in case the child `Subscriber` is `unsubscribed` on a thread other than the UI thread. If however this operator is above `observeOn` then it should work fine as `observeOn` would schedule the unsubscribe on the UI thread.

For example:

```java
// observeOn has no control over the unsubscribe of TestViewInput here
someObservable.observeOn(AndroidScheduler).lift(OperatorTestViewInput).subscribe(unsubscribeAtSomePoint)

// but in this one it would
someObservable.lift(OperatorTestViewInput).observeOn(AndroidScheduler).subscribe(unsubscribeAtSomePoint)
```

@zsxwing am I correctly explaining the edge case that this is here for?

> who should be responsible for making sure that UI related code is executed on the UI thread?

The `observeOn` operator ensures the `on*` events correctly get scheduled on the given `Scheduler`, in this case the `AndroidScheduler`. 

Unsubscribes however are flowing the opposite direction, so any operators or Subscribers below `observeOn` in the chain would need to handle their `unsubscribe` scheduling themselves (or use `unsubscribeOn`).