This is needed by several other PRs, so merging.

That context manager yields a file path but not a file descriptor.
I think, relying on file path is not a good idea as you can not transparently replace an in-disk file by an in-mem file.
When one's needs an explicit path, It should be the role of the caller to get the file path by fid.name

But that file can only be opened once, and is already open. It is probably best to leave the location of the temp files up to the system administrator. It is not unusual for it to be in memory, but then, it may run out of space...

I think we should use the same interface for all tempfile, whether in-mem or in-disk (see #6540) whether deleted on close or not.

A lot of utils can directly work on fid (thus memfile, like zip), and it can be much much much faster this way than writing tempfile on the disk. At least for np.savez, my purpose is to make it user choice even if in-disk is the default choice.

The problem come from the fact that the base class _TemporaryFileWrapper from python tempfile module
https://github.com/python-git/python/blob/master/Lib/tempfile.py deletes the tempfile on both close or exit methods. It should only delete the file on exit to be worthy on WinNT (for multiple close/open on the named tempfile) then we have our desired context manager.

Please note the choice of python to only return fid not path even for NamedTemporaryFile context manager. So all tempfile context manager have the same interface and can be transparently replace by io.BytesIO.

Moreover, If i read the comments of tempfile python module, there can be an automatic deletion by the winnt system on closing tempfile, that will be a pity in our case. As I do not have WinNT I can not check it;