Consider decoupling the bind / dom functionality from the core library

[mimshwright]

Hi! it's been a while!

When we first created this, the bind() method was everyone's favorite feature - that was back in the days when most websites used JQuery. Now that we have npm, I was thinking it would make more sense to remove the parts that interface with the dom into their own package. For example wanakana and wanakana-dom.

I like it because:

• it separates concerns of the code. Probably makes testing and porting to other languages easier.
• Perhaps limit the expectation that this code is going to "just work" with your text inputs 😉
• Should not be necessary for use with frameworks like React since they typically have inline event handlers on text components.

Don't like it because:

• Some users especially less advanced developers will have a hard time getting it up and running with minimal effort.

Thoughts? @DJTB et al

[DJTB]

Separation makes sense to me, I think we would mostly just move a few files: bind, unbind and dom.
Can probably remove some polyfills by now as well to cut down the bundle size.

Personally I don't have the cycles to implement this without a strong request for it, but I'm not opposed to it happening either.

Also, not a blocker, but worth nothing that for React etc, I would still always use bind and then work with the final value on submit/blur. Since the bind method handles mobile / IME input bugs that you really don't want to try to re-implement with inline handlers. Saves a bunch of headache as far as I'm concerned!