Feat: Implement IntoSplitSignal for (Signal<T>, SignalSetter<T>)

[jquesada2016]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

It would be great to be able to use bind:value with arbitrary Signals. However, since signals are not two-way, you can emulate this behavior by pairing it with some arbitrary SignalSetter.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Implementing the IntoSplitSignal trait for a Signal<T> and SignalSetter<T> tuple should do the trick.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

To make this work currently, one must use a supported splittable singla, and then use an Effect to sync the state between Signal and SignalSetter.

Additional context
Add any other context or screenshots about the feature request here.

N/A

[jquesada2016]

Thinking about it further, perhaps RwSignal::from((signal, setter)) might be a more generalized solution?

[gbj]

This turns out to be easy -- it's simply a matter of relaxing the bound on IntoSplitSignal to be Set instead of Update, since it only uses a setting behavior. (SignalSetter<T> doesn't implement Update, hence why the blanket impl didn't already cover it.)

I think this is technically a semver-breaking change (types that implement Update but not IsDisposed might not implement Set) so I did it against the leptos_0.8 branch, but we're planning on doing an alpha of that soon. (I am... on an airplane home from RustNation UK at the moment, but maybe next week some time.) There aren't big breaking changes in that release, it's all stuff like this.

Thinking about it further, perhaps RwSignal::from((signal, setter)) might be a more generalized solution?

This one isn't possible in general because there's no reason to believe that the Signal<_> and SignalSetter<_> were created from an original RwSignal<_> without a runtime check. It would be fine to do it with a runtime check to that effect, in which case TryFrom is probably better than From.