feat: print inner value in Debug impls

[Giovanni-Tably]

When developing websites in leptos it's very useful to be able to quickly debug-print various signals and see what's inside them. Accessing them is already an option, but it's verbose during a critical point in the iteration cycle and doesn't work well for nested signals.

No subscription happens when debug-printing.

The main issue here is that this means that debug-printing can panic if the signal is disposed of. We can partially work around that by using the try_ versions of the access methods, but we can't work around it for signals accessed within derived signals as far as I can tell.

We didn't expect this to be a problem, so internally we opted for consistency (every signal panics when accessed after disposal), but I can change it if preferred.

Finally, the added bounds are a breaking change. We didn't have any issues, but depending on the plan for future versions it might make sense to just close this and consider it in the future reactive system.

[gbj]

Thanks — This is an interesting one. I can totally see the usefulness to have actual debug values. On the other hand, the panic is a downside. (And the breaking change means it can't be merged, at least at the moment.)

It's worth a broader discussion IMO about how we think about trait implementations on signal-like types in general: are Debug, PartialEq, Hash, and so on "shallow" and unreactive, or "deep" and reactive? At the moment things like Serialize are "deep and reactive," PartialEq is "shallow and unreactive" (I think?), and so on. There are good reasons for this but I will grant that it's inconsistent.

[Giovanni-Tably]

Yeah, that makes sense.

I have elaborated a bit on some related reasoning in #2359 for PartialEq.

Maybe we can close this, and I can create an issue specific to 'shallow vs deep signal traits' to track discussion on this?

[gbj]

Sounds good to me.