mutations: specifying the type for errors

[michael-small]

Currently, the type for mutation errors is just unknown. So whether you are awaiting a mutation or just accessing the error in onError, you must cast or narrow your error if its type is knowable.

This issue is to track adding an error typing functionality. I have picked this up formally, but feel free to discuss.

To avoid breaking changes, we are thinking of adding an inferError: boolean which would be false for all versions <=21. And then in 22, it would default to true.

[michael-small]

@rainerhahnekamp after looking through our internal discussion about that inferError: boolean, I am not sure if that will be needed. My implementation in the linked PR preserves the errors being unknown by default, but can be specified with a third arg or with a parseError. The only thing I think is missing at this point, other than some tests, would be adding a parseError to rxMutation. Thoughts?

[michael-small]

@rainerhahnekamp I have been looking at this through the lens of mutation functions directly, but when looking at withMutation as a whole, the error or namedError is set to Signal<Error | undefined>. With the TS native type interface Error {cause?: unknown;}. With this wrinkle in mind, should we now go the inferError: boolean route again and have that allow the error generated from withMutation be inferred from the actual mutation inference?