This commit removes the previously added `rejectErrors` option from
`toSignal` which was meant to create similar behavior to what happens
with unhandled errors in `AsyncPipe`.

This option promotes unhandled exceptions and attaches behaviors that we
do not believe are desirable as an option offered by the framework:

* Unhandled errors that are thrown lose the context of where the error
  ocurred. Throwing the error where the signal is read allows error
  handling to be performed at the signal's usage location
* With this feature, the value of the signal remains set to the initial
  value or the previous successful value coming out of the `Observable`.
  We do not feel this is appropriate implicit behavior but should be an
  explicit choice by the application. Signals are built to represent
  state. When an observable stream is converted to a stateful
  representation, there should be a choice made about what state should
  be presented when an error occurs
* If an error occurs but the signal value is never read in its error
  state, this is not an application state error that should result in an
  unhandled exception.
* While Angular does not have error boundaries today, there is likely to
  be investigation in the near future to address increased risk of
  errors thrown from signals such as this in templates. Without
  pre-designing any specifics, it is possible that this type of feature
  would require the error to be thrown from the signal. We are subsequently
  not prepared to commit to stabilizing the `toSignal` API with the
  `rejectErrors` option and its current behavior.

Developers that desire similar behavior to `rejectErrors` have several
options, the simplest of which would be something similar to
`toSignal(myStream.pipe(catchError(() => EMPTY)))`.