Improve pathname2url() and url2pathname() docs

[barneygale]

These functions have long sown confusion among Python developers. The existing documentation says they deal with URL path components, but that doesn't fit the evidence on Windows:

>>> pathname2url(r'C:\foo')
'///C:/foo'
>>> pathname2url(r'\\server\share')
'////server/share'  # or '//server/share' as of quite recently

If these were URL path components, they would imply complete URLs like file://///C:/foo and file://////server/share. Clearly this isn't right. Yet the implementation in nturl2path is deliberate, and the url2pathname() function correctly inverts it.

On non-Windows platforms, the behaviour until quite recently is to simply quote/unquote the path without adding or removing any leading slashes. This behaviour is compatible with both interpretations -- 1) the value is a URL path component (existing docs), and 2) the value is everything following file: (this PR)

The conclusion I draw is that these functions operate on everything after the file: prefix, which may include an authority section. This is the only explanation that fits both the Windows and non-Windows behaviour. It's also a better match for the function names.

---

📚 Documentation preview 📚: https://cpython-previews--127125.org.readthedocs.build/

[barneygale]

I think the confusion came about because the original urllib author understood that file:/etc/hosts was the correct way to express /etc/hosts as a file URI. They weren't wrong per se, and it's still an acceptable form. But later on, it became much more prevalent to express that path as file:///etc/hosts, and some folks began to use pathname2url() and url2pathname() in a slightly different way. But the new definition never gelled with the Windows implementation, and traces of the old understanding can be found in the codebase and tests.

edit: actually, it might be due to a 90s-era misunderstanding between two devs