Add StoreBundle<T> type

[mustevenplay]

Summary

Here I added StoreBundle<T>; a useful type extracted directly from the createStore function's return type:
type StoreBundle<T> = [get: Store<T>, set: SetStoreFunction<T>]

How did you test this change?

This type is identical to the return type of the createStore function, so nothing really should change, besides the fact that it's definitely more portable, more compact, and depending on who we ask, more readable.
All tests have been successfully ran, though.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 7fdb766

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ryansolid]

This seems reasonable.. just thinking about naming.. Do the other Signal accessor pair have a name? Maybe consistent naming won't be possible until 2.0. Would love someone who looks at the TS conventions of this repo take a look.

[mustevenplay]

The current return type of createSignal is Signal<T>, which is alias to [get: Accessor<T>, set: Setter<T>]. In my opinion, the chosen names Accessor and Setter might be kind of ambiguous, to which I suggest we might want to try coming up with a convention that could unify return types of functions like createSignal or createStore with a naming such as "FooBundle" (like in this case, StoreBundle). Keeping the current naming could be a good idea too, but I could as well suggest to give it a specific name for each return type.
These conventions applied on the current Signal<T> type would look like this:

type SignalBundle<T> = [get: SignalAccessor<T>, set: SignalSetter<T>]