Solving safe/unsafe defaults

[annevk]

We have a problem currently that new Sanitizer() ends up being the same configuration for safe and unsafe, with completely different effects. This makes it really hard to design an API to manipulate the policy as the implications for safe and unsafe are different.

To solve this I think we could do the following:

1. Introduce Sanitizer.default() that returns the configuration we want setHTML() to use when no configuration is provided.
2. Make setHTML()'s SetHTMLOptions's sanitizer default to "default" rather than {}. setHTMLUnsafe() will continue to default to {}. "default" here is an enum value that means Sanitizer.default() and is needed to make things work IDL-wise. It will also provide us with a way forward for other named policies we might want to add in the future.
3. new Sanitizer() now represents an empty policy. So if you pass that to setHTML() you only get the XSS-blocklist impacting you.
4. We can continue to keep get() and getUnsafe(). get() is useful to see how your policy will be impacted by the XSS-blocklist.

This means that if you do setHTML("...", sanitizer: {}) you're only impacted by the XSS-blocklist. If you do setHTML("...") you get our more conservative "default" take.

Coupled with #229 I think this would provide all the building blocks we need.

[annevk]

3/4 are addressed by 7e2f127 and 1 is noted. But 1/2 still need to be done.

And note that 4 was morphed into the clearly better removeUnsafe().