message: docs: Add more detail to deprecation messages
  People were getting confused.
diff: # Subscribe Arguments
  You might have seen that we deprecated some signatures of the `subscribe` method, which might have caused some confusion.
  -The `subscribe` method itself is not deprecated. We just deprecated some of the signatures to improve readability and
  -API ergonomy. This deprecation also affects the [`tap` operator](../../api/operators/tap), as tap supports the same signature as the `subscribe` method.
  +The `subscribe` method itself is not deprecated. This deprecation also affects the [`tap` operator](../../api/operators/tap), as tap supports the same signature as the `subscribe` method.
  +
  +This is to get ready for a future where we may allow configuration of `subscribe` via the second argument, for things like `AbortSignal` or the like (imagine `source$.subscribe(fn, { signal })`, etc). This deprecation is also because 2-3 function arguments can contribute to harder-to-read code. For example someone could name functions poorly and confuse the next reader: `source$.subscribe(doSomething, doSomethingElse, lol)` With that signature, you have to know unapparent details about `subscribe`, where using a partial observer solves that neatly: `source$.subscribe({ next: doSomething, error: doSomethingElse, complete: lol })`.
  <div class="alert is-important">
  <span>
  @@ -14,6 +15,8 @@ In short we deprecated all signatures where you specified an anonymous `error` o
  ## What Signature is affected
  +**We have deprecated all signatures of `subscribe` that take more than 1 argument.**
  +
  We deprecated signatures for just passing the `complete` callback.
  ```ts
  