feat: add setAtom bound to the state manager

[jodarove]

Description

This PR proposes the addition of a new API for State Managers: setAtom, which allows state manager authors to directly update atom values without the need to use an update function. The API limits which atoms can be updated to only those that are created within the defineState function.

Before this PR:

const state = defineState((atom, _computed, update, _fromContext, setAtom) => () => {
  const count = atom(1);

  const increment = update({ count }, ({ count: countValue }) => ({
    count: countValue + 1,
  }));

  return {
    count,
    increment,
  };
});

After this PR:

const state = defineState((atom, _computed, _update, _fromContext, setAtom) => () => {
  const count = atom(1);

  const increment = () => setItem(count, count.value + 1);

  return {
    count,
    increment,
  };
});

Things to notice here:

1. With this version need to access the .value because we are directly using the atom.
2. Every operation after a setAtom, is affected by it because when setting it, it will mark all dependencies of this atom as “dirty” therefore recomputed in next access.
3. the function can be async and return a value.
4. ** Needs more thinking: what if the underlying implementation changes (ex, preact/signals), and increment is executed within, for example an effect, this this access will be register for that effect; therefore whenever count.value changes, the effect will be executed.

Followup proposal: can we remove the update function?

🟢 No breaking change

[mburr-salesforce]

can we do something to let consumers know that update is deprecated?

[jodarove]

since the package version is 0.x.y i was thinking about removing the update functionality entirely (working on it in a different PR).

[jodarove]

created https://github.com/salesforce/lightning-labs/compare/main...jodarove:lightning-labs:jodarove/remove-update-proposal?expand=1 (contains also this changes) (or this pr against this branch to show the isolated changes)

[mburr-salesforce]

I'd like to rethink the atom/setAtom names at some point & see if we can come up with something that has more immediate / imperative connotations. Doesn't need to be in this PR, though.

[jodarove]

sure thing, let's brainstorm on it!