vfs: apply open(2) effects to ZipProvider handles

[pipobscure]

vfs: apply open(2) effects to ZipProvider handles

A ZipProvider handle keeps its content in memory and adds the entry to
the archive when it is closed, and only if something was written. The
effects a real open(2) has at open time are therefore lost, and so is
the metadata the entry already carried:

• open(path, 'w') followed by close() neither truncates an existing
  entry nor creates a missing one; the same holds for "a" on a missing
  file. Tools that touch or truncate by open-then-close do nothing.
• Rewriting an entry (append, or an in-place write through "r+") re-adds
  it with the mode argument open() received (fs's default 0o666),
  not the mode the entry had, so a 0o755 script silently loses its
  executable bit.
• fstat on a handle reports that same open() mode and the current
  time instead of the entry's mode and modification time.
• Renaming a file onto an existing directory succeeds and leaves a name
  that is both a file and a directory; real file systems refuse with
  EISDIR.

This adds a test for each of these against a mounted ZipBuffer, stating
the real-fs outcome as the expectation.

Proposed solution: mark the handle dirty at open time when the flags
imply creation or truncation, so close always commits; carry the
existing entry's mode and modification time on the handle, use them
for fstat and for the re-added entry, and only fall back to the
open() mode for a newly created entry; and reject rename onto an
existing directory with EISDIR before touching the archive.

Note: Since these are gaps/defects in existing functionality, I decided to create the failing tests first (first commit) and then add the fix/solution as a second commit. That way whoever wants to review this can first prove out the issue, before applying the solution.

This goes with the VFS work by @mcollina and the bug-fix PRs by @trivikr.