plugins: command-regexp functions are now private

[Exirel]

Description

Fix #1887

• moved everything into sopel.plugins.rules, directly into each rule class
• removed/deprecated a bunch of stuff from sopel.test_tools (this entire module should probably be deprecated and removed at some point anyway)
• reworked imports in sopel.test_tools
• changed how the example decorator runs a test (this should be transformed further, probably in a future PR, for 7.1 or 8.x)
• removed obsolete tests and fixtures
• made sure the doc is still OK

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]

I have to ask: Are all of these changes really related to the PR/commit title, plugins: command-regexp functions are now private? This is a rare occasion when I really think you're doing too much in one commit, unless all of the refactoring and such is truly necessary to do all at once. I'd say at least some of it probably isn't, and should be a separate commit or PR.

Two things about the overall approach here, though:

1. The existing functions in tools should be marked deprecated until removal in 8.0, instead of yanked out in a point release with no warning. But nothing says we have to keep their implementation; what would you say to building the implementation inside Rule and its subclasses such that those tools functions would just call a classmethod or act as an accessor for the appropriate class constant?
2. Can we put tools.compile_rule into plugins.rules too? Same thing about deprecation vs. outright removal in 7.1, but it has no reason to exist outside the rule system especially if the rule system is its primary user.

[Exirel]

This is a rare occasion when I really think you're doing too much in one commit

I totally got carried away with that one, with a very bad case of tunnel vision. I'll see if I can separate that properly.

[Exirel]

I'll see if I can separate that properly.

Just did! I had to rebase everything, so I took that opportunity to fix the merge conflict as well.

[dgw]

Overall not a whole lot to say; mostly repeated suggestions for wording that's used in a half-dozen spots.

I complained about removing tests for the deprecated tools functions, but there was no place to leave a line note about making them just call the corresponding plugins.rules implementations until removal (what I suggested before).

[dgw]

@Exirel Pushed a couple commits to address my own feedback about test coverage and stuff. Instead of -0.1% coverage, the last PR build reported only -0.004%. 🏆

When it's time to straighten out the PR history, I suggest:

• "fixup" the appropriate commit with the partial revert (currently 3176636)
• either leave e4cd829 standalone or merge it with 1f4df30 (along with the other amendment, 452818c)

[Exirel]

I'm really not fan of your solution here: when something is deprecated, it's for a reason. This should not be modified, and there is only one way to ensure that: don't change the code. Now, if we want to change the code in, say, the regex we use for good, we'll have to take care of deprecated functions we don't want to change.

[dgw]

These deprecated functions we don't want to change are meant to return the regex or pattern for the type of command they specify. The regex isn't going to change between now and 8.0, at which point these will be gone.

But let's say we do want to change something. We'd have made that change in these functions before; now we make it in plugins.rules instead. I don't see a difference. If someone's code is going to break because the pattern/regex returned by this tool function changed, it's going to break regardless of whether said pattern/regex came from tools/__init__.py or plugins/rules.py. 🤷‍♂️

[Exirel]

@dgw rebased, keeping your changes. Should be good now.

[dgw]

Extra tests for the regex args, too, it's magnificent!

[Exirel]

Rebase because I want to work on the next step asap.