Extract @kbn/observable from the new-platform branch and PR it to master. That way we can discuss the observable details/apis separate from the architectural changes, and we can start relying on our implementation before merging the rest of the new-platform branch.

Moving forward, we will use rxjs directly.

Reasons

• Time. Is it worth it to build and maintain a thin wrapper around rxjs?
• Feature parity. Especially since we'd want to immediately support any breaking change from rxjs.
• No difference. We don't want to diverge from rxjs.
• Documentation. If we had a thin wrapper we'd still need documentation around it.

Utility functions

• If rxjs isn't enough, we can write new functions as needed.

Usage practices

• Education over restriction. If a feature has a propensity to be misused, like Subjects, educate developers rather than creating a wrapper or some blockade against using the feature.
• Error handling. Same here, educate on how best to avoid swallowing errors.