docs: split files into subfolders

[Exirel]

Description

Tin.

This is only a "first step" to reorganize the documentation around better chapters, and to rationalize where we put code references (i.e. documentation from docstrings).

I didn't change any text, it's really just moving things around.

This was initially based on #2237, #2226, and #2232, until they got merged.

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]

In lieu of a full review, which I don't really have the steam/spoons/whatever for at this moment, I would like to request that you create a patch for sopel.chat's _redirects file that will direct requests for the deleted/moved pages to the correct new locations. Not necessarily immediately, but before this is merged. :)

[Exirel]

I would like to request that you create a patch for sopel.chat's _redirects file

That's fair, I'll see it done.

[dgw]

Found some spoons. Didn't actually find that much to say, though. 😁

[Exirel]

I'll see it done.

But not yet, apparently.

[Exirel]

But not yet, apparently.

And now it is done! See sopel-irc/sopel.chat#38 for more information.

[Exirel]

@dgw you can review now! And remember, this is only a first step. There are so much more to come in term of documentation!

[dgw]

While I haven't actually gone back over this again line-by-line, I'm aware that there will be more documentation patches coming before 8.0. There will be plenty of time to add/fix more stuff.

If nothing else, approving this means you can start on the next phase (new branch based on this one). The only thing I ask for now is to address _redirects in sopel-irc/sopel.chat#38 (patch and/or comment). 😸

[dgw]

I'm gonna trust GitHub when it says I've still "viewed" all the changed files, and therefore trust that the diff is the same as what was approved. Rebasing pulled in way too many changes from the base branch for me to sort through those. 😅

(Yes, I still wish you wouldn't rebase "just because", when there's no merge conflict, @Exirel. And if you insist, please remember to update your remotes first… The apparent new base commit, 8b463a0, is old! 😝)

[Exirel]

I didn't rebase on the last version of master, IIRC, but I have to if I want to squash commits, don't I?

[dgw]

You don't have to rebase onto any particular commit, but it's likely that you'll get "the last common commit between this branch and master" by starting your rebase with git rebase -i `git merge-base HEAD master` (note backticks; this is for Bash).

At least, I tried that on one of my somewhat stale topic branches and it started a rebase against the expected commit. YMMV as with most one-liners. There is a --fork-point flag for merge-base that may or may not affect the result, depending on exactly what the branches look like (but for how we usually use topic branches, probably doesn't matter).