Revisit polyfilling

[ZeeCoder]

It might worth reconsidering the polyfilling issue.
Originally I shipped all necessary polyfills to make it easier to adapt the library, but that comes with some cons:

• Shipping the polyfill adds extra weight to the lib
• If the polyfill is applied automatically, then that could be applied before the app developer applies its own polyfill => this could result in hard to debug situations, where this lib would polyfill something sooner than the app developer.

Using something like polyfill.io, or just a separate polyfill js file made by the app author should be an easy enough thing to do, since I'm already assuming a lot of knowledge with these modules anyway.

Anyway, needs some more research into polyfilling best practices.

[ZeeCoder]

I wonder if it would be possible to ship polyfilled and non-polyfilled versions. 🤔

[ZeeCoder]

note: Look into babel-preset-env, which is supposedly able to auto-polyfill source code by injecting require statements where needed.
(It still probably doesn't polyfill ResizeObserver though.)

[ZeeCoder]

Still no easy solution for this (w3ctag/polyfills#6) but shipping a polyfilled / /non-polyfilled version seems like the best way for now.
(Where polyfills should be included in the lib in a way that does not affect globals.)

[ZeeCoder]

UMD support will probably need to be dropped, as automatic polyfilling causes some weird issues with it. (cjs, esm are both fine)
I can polyfill most things automatically, but ResizeObserver will be a harder nut to crack:
babel/babel#7328