admin: add .raw command to send raw IRC messages

[half-duplex]

Description

Adds a .raw command to admin.py to allow commanding the bot to send a raw IRC message, e.g. .raw OPER Sopel ThisIsABadIdea123

Checklist

• I have read CONTRIBUTING.md
• I can and do license this contribution under the EFLv2
• No issues are reported by make qa (runs make quality and make test)
• I have tested the functionality of the things this change touches

[dgw]

Simple and to the point. Only usable by owner in PM makes sense. The code review is not a sticking point here; I just wonder about privesc as @Exirel mentioned on IRC. For example, .raw MODE #channel +o EvilOwner could bypass the very intentional usage restrictions on .op from the adminchannel plugin.

Of course anyone who gives a bot +o on a channel must implicitly trust the bot's owner not to overstep, so that's no reason for a hard rejection. EvilOwner could just as well write a very simple plugin to opportunistically take over channels where the bot has op, even without the .raw command. But we should still think about this. It could be prudent to put in a separate plugin, for example, so it's easy to disable without losing the rest of admin's functions.

[half-duplex]

The only way I can come up with that this could be abused is if the bot owner were impersonated and they wanted to do something that was not possible with an enabled builtin command.
Impersonation isn't an especially high bar, requiring either a loose bot configuration or a network that doesn't have account-tag.
In the default configuration, the second part mostly means OPER things, which obviously require the bot to have OPER. If a bot owner has adminchannel.py disabled and has the bot +o, it would also include things like MODE #chan +o Mallory.

On one hand, we can't save everyone from everything - .say allows any bot admin to .say ChanServ OP #chan Mallory if the bot's not ACL'd properly, or just .say #chan !op Mallory in a channel where another bot trusts any op to use that command... Have I mentioned that I don't understand the need for the .op command at all?

On the other hand, I suppose it is a relatively niche need, so maybe it does just belong in everyone's .sopel/modules/debug.py - I wrote the patch while thinking we had a specific need for it, that I realized was obviated by the already-existing .say NickServ [...]. Maybe a builtin debug.py, except we can't elegantly default-disable modules, and owners have .load.

[dgw]

Maybe a builtin debug.py, except we can't elegantly default-disable modules, and owners have .load.

A suite of debug tools could be its own PyPI package, though. It would be disabled by default because the bot owner would need to install it. We're moving toward (almost) all plugins being packaged separately, anyway.

sopel-ipython is basically a debugging-tool package, already moved out of core because its dependencies got annoying.

[dgw]

Suffice it to say that, regardless of where we land on having a plugin for debug tools, whether core or external, this is good to go. Nothing is unchangeable.