feat: makes defineState to receive an object with exposed APIs

[jodarove]

Description

This PR aims to improve the DX when defining a state manager.

Before this PR the defineState callback receives a set of APIs as arguments, example: defineState((_atom, _computed, _update, fromContext) =>.... The main inconvenients are:

1. you need to declare all of them until you find the one you want (fromContext)
2. As the framework evolves, we may add more apis, and the list could go on.

This PR targets those, by making the defineState callback to receive a set of APIs in the form of an object, in that way the users could desctuct only those that will be used in the state manager: defineState(({ fromContext }) =>...

🔴 This PR is a breaking change.

Note: the CI is failing with an error (seems to be unrelated to the changes as they pass in my local).

 ❌ Failed to launch the browser process!
[2117:2117:0327/194345.164448:FATAL:zygote_host_impl_linux.cc(126)] No usable sandbox! Update your kernel or see https://chromium.googlesource.com/chromium/src/+/main/docs/linux/suid_sandbox_development.md for more information on developing with the SUID sandbox. If you want to live dangerously and need an immediate workaround, you can try using --no-sandbox.
[0327/194345.173119:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq: No such file or directory (2)
[0327/194345.173159:ERROR:file_io_posix.cc(145)] open /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq: No such file or directory (2)

[divmain]

Does all the type inference continue to work with this change? I'm in favor so long as the types (internal and external) can still be inferred when writing & consuming a state manager.

[jodarove]

yep, the type inference is working!