[http- unzip_http] handle errors in retrieving URLs

[midichef]

This PR catches a few more error cases when retrieving URLs. Every new case handled is a situation I triggered in testing.

So for example, the stack trace on a nonexistent zipfile from a 404 with a particular server configuration:

        File "/home/midichef/.venv/lib/python3.12/site-packages/visidata/loaders/unzip_http.py", line 158, in infoiter
            self.zip_size = int(resp.headers['Content-Length'])
        File "/home/midichef/.venv/lib/python3.12/site-packages/urllib3/_collections.py", line 260, in __getitem__
            val = self._container[key.lower()]
        KeyError: 'content-length'

becomes cannot open URL: status code 404.

The web servers that host data tend to be poorly maintained, so visidata users will run into such errors unusually often.

Tested on Python 3.8 and Python 3.12 to make sure the Exception classes exist in the oldest and newest libraries.

[saulpw]

This file (unzip_http.py) should be taken directly from https://github.com/saulpw/unzip-http/blob/master/unzip_http.py, with the vd.importExternal line being manually substituted. It's not a clean process but I didn't/don't expect unzip_http to be updated that often. They've already drifted a bit, but if we could bring them into sync again and make these changes in a way that keeps them as close as possible, that's my preference. Probably the easiest way is to let these errors percolate up and then handle them at a visidata layer instead of in unzip_http.

[midichef]

One complication is, unzip-http uses urllib3, so the exceptions would be from urllib3 and can't be caught in loader/archive.py which does not import it.

I submitted a draft patch that transforms the urllib3 errors into regular urllib errors. What do you think of that? It makes sense in the context of visidata, but it's quite odd in the context of unzip-http by itself.