Change `Path` into a wrapper around `java.nio.file.Path`?

[lihaoyi]

We could preserve the type-level distinction between Path and RelPath, as well as the nice superficial syntax and API. But there are things in nio.file.Path that I want:

• The concept of a Root http://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html#getRoot(), which should help with Ammonite-Ops doesn't handle multiple drives on windows #120
• Support for virtual filesystems, such as https://github.com/google/jimfs
• The ability to perform cross-filesystem operations! Copying & moving files to/from virtual and real filesystems, or across different roots, which is impossible unless that paths themselves have pointers to the filesystems they live on
• Easier interop with the rest of the java.nio world

This would be a non-trivial philosophical change that would change Paths from a transparent struct into an opaque type. Or at very least contain a pointer to an opaque type, the java.nio.file.FileSystem.

In general, the variables holding the Root and Filesystem have to live on the paths if we want to be able to perform operations that span multiple Roots or Filesystems, which we probably do. In the simplest case, Windows users would need to move files between drives.

This is impossible if you store the Root and Filesystem anywhere else, e.g. on the operations (e.g. D_drive.cp, C_drive.rm) because you won't be able to refer to paths on multiple drives in one operation.

This would also make it more awkward to use (abuse?) Path and RelPath for other non-filesystem usages. That could be considered a good thing. I've done this and it always proves to be confusing. Better to define a separate non-ammonite Path and have the types keep you straight

[lihaoyi]

This has happened in master and will go out 0.6.0