db: channel lookup should be case-agnostic, like nickname lookup

[dgw]

Requested Feature

Nicknames have this neat feature where the database can look them up case-insensitively, using a "slug" value that has been casemapped using the tools.Identifier machinery.

Channels should get this feature too, for parity.

Problems Solved

I honestly couldn't point to a concrete benefit right now. Maybe for very rare cases where a channel is renamed and the new value would be expected to casemap identically to the old one—but it doesn't, so the channel's settings get "lost".

Or on some IRCds/networks, the channel name you JOIN is whatever name gets passed to the JOIN command and isn't enforced to be the canonical channel name registered with services. Maybe there are no services. Editing the bot's configuration could change the channel_values lookup in the DB (subject to the database backend's casemapping behavior).

It's an easy manual fix in the DB, to be fair, but these are still situations that shouldn't affect the bot.

Alternatives

The only reasonable alternative is to leave things as they are. Which we can do, since channel names don't change that much, but it's silly not to take advantage of the fact that channel names are also represented by tools.Identifier objects.

Notes

Fun fact: There actually is a (draft) IRCv3 specification for channel renaming. My hypothetical under "Problems Solved" was based on the more traditional kind of channel "move" where the old name is just dropped and a new one created, but that's a workaround if all that needs to be changed is some character casing. (The draft RENAME spec specifically requires that "Implementations MUST allow channels to be renamed while only changing the casing of a channel name.")

While it's debatable how useful nickname case-insensitivity even is compared to the complexity it introduces in the database, we should definitely simplify how that works on the way to giving channels the same functionality.

We'll need #1784 done before we can mess with the schema at all, though, so this issue clearly belongs in "Long-term Planning".