Sanitizer config introspection.

[otherdaniel]

This came up during TAG review (w3ctag/design-reviews#619): "Exposing the config on Sanitizer instances (possibly read-only) could provide an easy solution for this use case. Exposing the default config as a static property on Sanitizer might be helpful too."

• A similar thought came up in How to build derived configurations? #64.
• A similar mechanism existed in very early versions of our (Chrome's) implementation (.createOptions property)
• TAG considers whether this should be elevated to a design principle: APIs should allow introspection w3ctag/design-principles#300

I think the specific question raised by TAG (how to block a specific element) can be resolved elsehow (namely by blockElements:), but I think the general question remains: Should we support query-ing any sanitizer instance's config, and/or the default config, with the primary use case being building a derived configuration.

[iVanlIsh]

I would vote for we should since it looks like a fairly convenient feature for the developers.

[mozfreddyb]

Yes! I think it would be really useful to expose the defaults (in the Sanitizer global) and an instance's config (through an attribute).

[otherdaniel]

Good. I've started spec-ing something; will send a PR soon-ish.

"through an attribute": WebIDL spec says attributes can't be dictinonary-valued. I don't understand why; but I've picked parameter-less methods to be safe. (Am super happy to change in case I misunderstood this.)

[otherdaniel]

Resolved (#80).