cli: look harder for $PWD/cfg, don't automatically start wizard

[half-duplex]

Github won't let me reopen #2093.
+Bugfix because it now prints the .cfg path instead of ".sopel/foo"

Description

This fixes two annoyances:

• Sopel automatically adds .cfg when searching the config dir, but it doesn't when searching the current working directory
• If the config file is not found, it currently automatically starts the configuration wizard.

Combining these two, a user (me) will (does, regularly) cd to their non-default Sopel config dir, run sopel -c mybot expecting it to load mybot.cfg and run, but instead have Sopel create ~/.sopel/ and ~/.sopel/mybot.cfg and start the config wizard.

Searching $PWD/{config}.{ext} is straightforward, but not automatically running the wizard is probably subject to opinions. I changed it to the below output, but I would also be content with "Do you want to run the configuration wizard? y/n", or at least not creating the folder/file until the end of the wizard so the user has an opportunity to ^C without having to then rm -rf ~/.sopel

Amended "couldn't find config":

$ sopel
ConfigurationError: Unable to find the configuration file /home/user/.sopel/default.cfg
If you're just setting up Sopel, welcome! You can use `sopel configure` to get started easily.

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

[Exirel]

I didn't check all the docstring, but I believe it would be better to check more of them. This is a clear behavior change, one that I agree with, but I really don't like that docstrings and/or documentation have not been updated accordingly. This is user facing, so it is of the upmost importance.

[Exirel]

Just a nitpick. Looks good to me otherwise.

[Exirel]

I added the label breaking change because it changes the behavior of an existing feature that was kept as is between Sopel 6.9 and 7.1. I think it's an acceptable change that also need a fair warning to our users in the release note, without needing a whole deprecation cycle.

[Exirel]

Same nitpick as dgw regarding the blank line needed after the rst directive. I'm not worried about missing something, the basics are covered nicely with docstrings and tests, as far as I can tell.

[dgw]

Through the magic of git merge --no-ff --no-commit, I will take care of the whitespace without needing another force-push.

Edit: That was a lie; I forgot to git add the whitespace change before committing and pushing the merge. GJ me. 😅