Improve internal channel mode handling

[cooper]

This issue is a checklist for several others which are related but have to be completed in a particular order.

• Mode letters have to be manually looked up when generating mode strings (Mode letters have to be manually looked up when generating mode strings #77).
  • New channel method ->handle_modes() will be the low-level modes applicator.
  • Mode blocks need to be passed user objects rather than UIDs and nicks.
  • Mode blocks need to return user objects rather than array references of UIDs and nicks.
  • New channel methods ->do_modes() and ->do_modes_local() will be wrappers to a new ->_do_modes() method which will:
    • Accept a hash in the form of an array reference of mode names which MAY be negated. Values are string parameters or undef if no parameter is present. See the main issue for a detailed description of this method's arguments.
    • Apply the new modes. The new method will use the same logic for this as is presently in ->do_mode_string() and friends, calling mode blocks when appropriate.
    • Notify local clients when necessary. This MAY be split up into multiple MODE messages, depending on a configurable limit.
    • Unless the local version of the method was used, notify other servers.
  • New server method ->strings_from_cmodes() will:
    • Accept modes in the same form used by ->do_modes().
    • Take a parameter which specifies whether the strings should use UIDs or nicknames.
    • Take a parameter which specifies whether to split the changes up into more than one string.
    • Take a parameter which specifies whether to organize the modes alphabetically.
    • Return one or more mode strings.
  • New server method ->cmodes_from_string() will:
    • Accept a mode string in the perspective of some server.
    • Return a hash reference of named modes in the form used by ->do_modes().
• On JELP burst, only one MODE message per channel is sent to users (on JELP burst, only one MODE message per channel is sent to users #70).
  • In order to fix this, we need to make ->do_mode_string() a wrapper for ->do_modes().
  • First it will call ->cmodes_from_string() and then apply the result with ->do_modes().
  • Although this issue does not usually apply to TS6, it would fix an analogous problem with pseudoserver packages that may send large mode messages.
  • JELP and TS6 handlers will be unchanged. All of this new magic is internal.
• Mode changes in a single client MODE message are currently unlimited (Mode changes in a single client MODE message are currently unlimited #25).
  • Truncate mode parameters sent in a client MODE message to a configurable limit.
  • Truncate mode letters sent in a client MODE message to a configurable number of characters.