Specify handling of IDN / Unicode chars in origins

[clelland]

We should specify how IDN origins are handled, and what we do with unicode in the list of origins in in a policy string.

We could probably go one of two ways on this:

1. Run all non-ASCII origin components in the policy through normalization and punycode, and use the resulting ASCII serialization when constructing the origin, or
2. Disallow non-ASCII characters in policy strings, and require developers to do the serialization when constructing the policy.

[clelland]

I'm proposing that we go with #2 -- the list of origins needs to be ASCII, developers need to serialize any IDN to ASCII when constructing the policy declaration, and the browser will compare a document's serialized origin to the policy when determining whether to enable a feature. (This matches the current implementation in Chrome)

I'll update the spec to match this, unless there are objections.

[RByers]

It should be pretty safe to add support for 1. in the future if we decide it's worthwhile, right? Obviously there's some compat risk of sites depending on strings that were getting ignored, but that sort of risk tends to be pretty minor in practice. Given that, I'd agree we should just do the simple thing in 2. for now.

[annevk]

What is the processing model here? I think that for origins delivered over the network we should always do a string compare. Not entirely sure for origins given in markup though.