Add Zip support

[wb14123]

Resolves #161. Add Zip support.

os.zip(path) to read/write zip file. File will be created if not exists.

zipFile / subPath to get a path. Should be able to support all the file operations like copy, move, delete and so on.

[wb14123]

Hi @lihaoyi , this is ready for review

[lihaoyi]

@wb14123 looks like a good start. Need a few more things according to the original ticket:

1. Conveniently creating zip files from folders
2. Unzipping zip files into folders
3. Support for the various flags that zip and unzip support, where reasonable:

Below are the various flags on my OS-X laptop, I assume Linux zip has similar ones

lihaoyi mill$ zip --help
Copyright (c) 1990-2008 Info-ZIP - Type 'zip "-L"' for software license.
Zip 3.0 (July 5th 2008). Usage:
zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list]
  The default action is to add or replace zipfile entries from list, which
  can include the special name - to compress standard input.
  If zipfile and list are omitted, zip compresses stdin to stdout.
  -f   freshen: only changed files  -u   update: only changed or new files
  -d   delete entries in zipfile    -m   move into zipfile (delete OS files)
  -r   recurse into directories     -j   junk (don't record) directory names
  -0   store only                   -l   convert LF to CR LF (-ll CR LF to LF)
  -1   compress faster              -9   compress better
  -q   quiet operation              -v   verbose operation/print version info
  -c   add one-line comments        -z   add zipfile comment
  -@   read names from stdin        -o   make zipfile as old as latest entry
  -x   exclude the following names  -i   include only the following names
  -F   fix zipfile (-FF try harder) -D   do not add directory entries
  -A   adjust self-extracting exe   -J   junk zipfile prefix (unzipsfx)
  -T   test zipfile integrity       -X   eXclude eXtra file attributes
  -y   store symbolic links as the link instead of the referenced file
  -e   encrypt                      -n   don't compress these suffixes
  -h2  show more help

lihaoyi mill$ unzip --help
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.  Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.

Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir]
  Default action is to extract files in list, except those in xlist, to exdir;
  file[.zip] may be a wildcard.  -Z => ZipInfo mode ("unzip -Z" for usage).

  -p  extract files to pipe, no messages     -l  list files (short format)
  -f  freshen existing files, create none    -t  test compressed archive data
  -u  update files, create if necessary      -z  display archive comment only
  -v  list verbosely/show version info       -T  timestamp archive to latest
  -x  exclude files that follow (in xlist)   -d  extract files into exdir
modifiers:
  -n  never overwrite existing files         -q  quiet mode (-qq => quieter)
  -o  overwrite files WITHOUT prompting      -a  auto-convert any text files
  -j  junk paths (do not make directories)   -aa treat ALL files as text
  -C  match filenames case-insensitively     -L  make (some) names lowercase
  -X  restore UID/GID info                   -V  retain VMS version numbers
  -K  keep setuid/setgid/tacky permissions   -M  pipe through "more" pager
See "unzip -hh" or unzip.txt for more help.  Examples:
  unzip data1 -x joe   => extract all files except joe from zipfile data1.zip
  unzip -p foo | more  => send contents of foo.zip via pipe into program more
  unzip -fo foo ReadMe => quietly replace existing ReadMe if archive file newer

We don't need to support all of them verbatim, but on a case by case basis:

1. At least we need to support the ones that do things that are impossible using the current PR API: e.g. zip -0 to -9, or zip -c
2. Some of the flags may technically be possible using the common API, but we should probably provide support directly for convenience: e.g. creating zips with zip -x and -i, or unpacking zips with unzip -x, maybe we can let our Scala API take a Set[os.SubPath] or a os.SubPath => Boolean filter as part of creating or deconstructing zips
3. Some of the flags may be substitutable with usage of the existing zip-file-as-filesystem API you already implemented: e.g. zip -d, zip -m, or unzip -l, in which case we should document how to perform that workflow in a unit test using the os.zip primitives that you do provide
4. Some of these flags are irrelevant (e.g. zip -h2, unzip -M), or may be difficult/impossible to implement on the JVM.

Exactly which flag goes into which category is a subjective judgement. In terms of next steps, how about you go through the list of zip flags (either the ones I provided or the ones on your computer, doesn't really matter) and categorize them into the 4 categories above, and list out your categorization as part of the PR description. Then we can ensure that the ones that deserve special support are supported, and the ones that can be emulated via other workflows have those workflows tested and exercised.

Lastly, we need to include this in the documentation. One you have the categorization/implementation/tests finalized, it should be pretty quick to copy paste the necessary parts of each into the readme.adoc with a few words to explain how they are used

[sideeffffect]

Since fs is created internally, shouldn't the class zip implement Closeable?

[sideeffffect]

Could a Map[String, String] be an optional parameter to the class constructor with this as the default value? That would make it configurable from the outside.