E-mail address canonicalization additions

[ilbelkyr]

This isn't quite complete yet but does aim to address #736. So far, this adds:

• nickserv/canonmail to let services operators debug their canonicalizer configuration
• misc/canon_domains module to canonicalize multiple email domains into the same

There's no documentation for this in the example config or NEWS.md yet. I'll add that once #757 is merged so there won't be a need to resolve merge conflicts.

Potential things to add before merging this:

• wildcard support for canon_domains? Not sure if this is needed; it wouldn't be too hard to add
• do we want to allow this to be configurable via IRC?
  • do we allow IRC and file-based config to coexist (as is the case with operserv/soper and operator {} blocks right now)? how would we handle conflicts?
  • we could also allow either file or DB based config but not both concurrently – less flexible but also less confusing (both for network staff and implementation-wise)
• optional dot stripping in localparts (foo.bar@ into foobar@)
• optional removal of plus extensions (foo+bar@ into foo@)
  • allow a separator other than + to be configured
• how would the above interact with canon_domains, would it be reasonable to make them configurable on a per-provider basis? can per-provider config coexist with per-domain config?
• do we want this to interact with badmail?
  • currently, badmail doesn't care about canonicalization at all
  • making badmail check the canonicalized email would allow badmailing an entire provider by banning what it gets canonicalized to – currently, that'll be the shortest domain, which isn't super intuitive
  • how reasonable would it be to consolidate this with badmail for an all-in-one email address configuration interface?
    • would definitely need the IRC-side config part
    • could have per-provider/per-domain "blocked" setting with customizable message and internal reason (cf user-facing BADMAIL reasons would be cool #740 as well)
    • keep BADMAIL interface for compatibility?
• a lot of the above could arguably be provided by modules with a suitable mechanism to hook into a generic email configuration module

(I might be overthinking things a little)