Move back to mainline `vcrpy` with `urllib3` 2.x when possible

[dgw]

Follow-up to #2455. We only want this pinned temporarily, as described in 6e64c96; when possible, the pin should be removed.

Relies on resolution of upstream issue, kevin1024/vcrpy#688

[dgw]

#2519 made unpinning urllib3 possible, and the upstream issue in vcrpy has been "closed". But we're still doing Kludgy Things related to both packages:

sopel/dev-requirements.txt

Lines 20 to 22 in 973a489

	# use fork of vcrpy 5.x until kevin1024/vcrpy#777 is (hopefully) accepted
	# (or until py3.9 EOL... in 10/2025, I HOPE NOT)
	vcrpy @ git+https://github.com/sopel-irc/vcrpy@uncap-urllib3

I will retitle this issue to reflect the current state, which is that vcrpy might or might not ever officially support using urllib3 2.x on Python <3.10 given problems with vcrpy's test suite on those combinations. There's no guarantee that I'll ever manage to get my patch into a state acceptable to upstream (but the test failures happen only in the suite's "offline" mode that mocks out actual communication with a server, seeming to work just fine when talking to real servers).

[dgw]

Quick update summary:

• The upstream patch I made hasn't gone anywhere, because while it works for us it doesn't seem to be compatible with the full set of features and library combos vcrpy supports. I've stopped pushing for it since py39 is so close to EOL.
• We now have to pin urllib3 so it won't break (build: pin urllib3<2.3 to accommodate our old fork of vcrpy #2647) with vcrpy 5.x
• I now look forward to dropping Python 3.9 later this year… That's the last version affected by this issue.

I might formally propose skipping vcrpy tests on the older Python version anyway, if I get the bee in my bonnet to bring that component current sooner. The house of cards pile of pins can only get so tall before it really annoys me.