When a certificate represents a hostname, or a client requests one, that

hostname may be presented in any casing (uppercase, lowercase, mixed

case), which can pose issues for comparison. Further, when dealing with

filesystem storage, we may encounter hostnames with non-ASCII characters

in them, which may pose challenges depending on the filesystem.
This change introduces casing normalization of hostnames in the storage

objects to ease comparisons, and normalization/encoding/decoding in the

file storage backend to handle encoding and representation differences.
The base storage objects that deal with hostnames now keep a version of

the hostname normalized for comparison purposes. This is a Unicode

string that can resolve to a hostname, but with casing converted to

lowercase. This eases comparison and gives a consistent representation

of these hostnames.
The file storage backend handles its own normalization and translation

behavior when computing filenames for a given hostname. Encoding

involves removing any trailing period on the hostname and then

then converting to an IDNA 2008 representation to handle Unicode

characters. The result is an ASCII filename safe for all filesystems.

Decoding does the inverse of this.
IDNA handling depends on the idna library, which is a new dependency

added to Review Board 8. This supports IDNA 2008 standards with UTS46

normalization, which amongst other things handles casing differences.
Note that the standard Certificate, CertificateFingerprints, etc.

objects do not normalize hostnames. They are a representation of their

source. Whether that source is caller-supplied input, an X.509

certificate, or a storage object, it will reflect the version of the

hostname on there. That allows for creating an object that can represent

a piece of state that can then be introspected or validated, which we do

today.

Unit tests pass.