Support cross-origin stylesheets when CORS enabled

[flackr]

In #78, @calinoracation mentioned that there are cases where external stylesheets are used from CORS-enabled origins, where it would also be nice to support scroll driven animations.

We could one of the following:

1. Have some kind of allow list or option to change the behavior. This would be an exposed API surface that is not part of the public scroll driven animation API, or
2. Have a build preference that changes the above behavior, or
3. Try to load the stylesheet anyways and fail gracefully if it's not CORS-enabled.

I think I'm leaning towards option 3 as it seems simplest.

[calinoracation]

I personally like option 3 as well. My only real concern is the potential for it to blow up alerting systems that might be listening to fetch failures globally and reporting on them. That's probably a reasonable thing, but it might also lead to a bit of unexpected perf hits.

For example all of the google fonts come via external stylesheets and would all be parsed in this manner, as well as any other externally injected stylesheets from ad servers and such.

Not saying I'm advocating for option 1, but it has some additional advantages:

• Allows consumers to restrict only the origins we know should be parsed
• Allows consumers to import the package but then schedule addition of the polyfill perhaps after first meaningful (to product) paint
• Gives a new configuration point for example if we want to split up the CSS / JS parsing options in the future as is already proposed

The build preference for it could also be one that uses those options, but it doesn't seem as appealing to me. Feels like either get all the good stuff out of the box on import or you want to take a more manual approach.

[bramus]

An allow-list defaulting to * seems the most practical to me. Works out of the box for most, allows finer configuration for those who want.