v0.6.0

Added (Phase 7a new schemes, stdlib-only, no new deps)

• data: scheme (RFC 2397, pathlib_next.uri.schemes.data.DataUri):
  read-only, no backend/connection -- the entire file content is embedded
  in the URI (data:[<mediatype>][;base64],<data>). stat().st_size is
  the decoded payload length; iterdir() raises NotADirectoryError
  (it's always a single file); write operations raise NotImplementedError.
• ftp:/ftps: scheme (pathlib_next.uri.schemes.ftp.FtpPath): full
  read/write/list access via stdlib ftplib, with a thread-keyed LRU
  connection cache mirroring sftp.py. Listing/stat prefer MLSD (RFC
  3659); servers without it fall back to NLST (listing) and SIZE
  (file-only stat). Writes buffer in memory and upload via STOR/APPE on
  close(). chmod() uses the common but non-standard SITE CHMOD
  extension (may not be supported by every server).
• zip:/tar: archive paths (pathlib_next.uri.schemes.archive):
  <scheme>:<archive-uri>!/<inner-path> (Java-style !/ separator,
  URI form proposed to and confirmed by the user before implementation).
  The archive half is itself any absolute URI with an explicit scheme, so
  archives are readable straight off any other backend (file:, http:,
  sftp:, ftp:, data:, ...). Read is supported for both schemes.
  Write is zip:-only, and only for brand-new entries in a local (file:)
  outer archive (overwriting/deleting/renaming an existing entry would
  need a full-archive rewrite -- not implemented, raises
  NotImplementedError). tar: auto-detects .tar.gz/.tar.bz2/.tar.xz
  compression and is always read-only.

Full Changelog: v0.5.0...v0.6.0