Move registerDomBinding to the createApp interface

[ThaNarie]

Original task

Currently the registerDomBinding function is standalone, acting as a global.

With the "recent" introduction of the createApp function, acting as the starting point of any app, it might make more sense to move the registerDomBinding to that location, scoped to the app.

Even though the internal implementation might still use the bindingsList global (mostly for typing and use in applyBindings), that is all handled internally.

Moving this function will make the external API more future proof and stable.

The problem with this change, is that you might not always have access to the app instance. Example here is inside storybook, where muban-storybook is responsible for creating the app instance. There is currently no way to access this app instance from any component.

Questions

1. Should we move these kinds of functions to the app instance?

Pro; it feels more at home
Con; the types you have to update are global anyway, so why not keep the function global?

Other examples are component and provide/inject.
For provide/inject this can be added to any component in the change.
For component there is a workaround for Stories specifically, but this feels like a workaround.

2. Should we allow access to the app instance from all components

If we move these functions to the app instance, should we allow access to the app instance from all components

Or maybe dedicated hooks to interact with it (like provide/inject)?

[psimk]

1. Should we move these kinds of functions to the app instance?

This makes sense as we would be binding the bindings to a specific instance of a Muban app. It would allow us to create different Muban instances, with different bindings.

I think the type being global is fine, as long as we expect that most Muban app's will be single-instance. For environments such as Storybook or when we do need multiple instances, we should allow passing a binding generic to the component to override the global type. styled-components DefaultTheme works in this exact way - you can globally define it, but can also change it on a per-component basis.

2. Should we allow access to the app instance from all components

I think that exposing the rest of the app to each component is quite dangerous, as any of the fields are susceptible to change. Moreover, it would be possible to store the instance or any of its fields in ways that we don't intend to, which might cause memory leaks.