feat(docs): Stateful vs Side-Effectual Runes

[leoj3n]

Describe the problem

I'm wondering if we can break runes into two camps for better organization and understanding, especially as a nice-to-have for newcommers reading the runes documentation. This thinking may influence what functionality is moved into "runes", similar to as what is discussed in issue #9451

Describe the proposed solution

For what exists today, I think you might be able to categorize runes as either "Stateful" or "Side-Effectual":

• Stateful runes (State runes?)
  • The "runes" that get, set, or pass around reactive state.
    • $props
    • $state
    • $derived
    • $derived.by
• Side-effectual runes (Side-effect runes?)
  • The "runes" that are meant to re-run when state changes.
    • $effect
    • $inspect
    • ($unstate?)
    • ($untrack?)
    • ($navigate?)

Importance

nice to have

[dummdidumm]

Giving this the 5.0 label in the sense of "we can close this once we've resolved the final docs", and as food for thought we don't forget

Agree that splitting them up is probably worthwhile. I'm not sure how to best model it yet, but maybe it's time for a split between "guide" and "reference", where guide gives an overview of these things with how to use, and "reference" is one rune per page with very in-depth explanation about all the nuance.

[dummdidumm]

Closing since we're gonna have docs in that direction, and this issue was only kept open as a reminder to do this, which we are now.