Parallelise the details view!

This commit removes the threadpool in `main.rs` that stats each command-line argument separately, and replaces it with a *scoped* threadpool in `options/details.rs` that builds the table in parallel! Running this on my machine halves the execution time when tree-ing my entire home directory (which isn't exactly a common occurrence, but it's the only way to give exa a large running time)

The statting will be added back in parallel at a later stage. This was facilitated by the previous changes to recursion that made it easier to deal with.

There's a lot of large sweeping architectural changes. Here's a smattering of them:

- In `main.rs`, the files are now passed around as vectors of files rather than array slices of files. This is because `File`s aren't `Clone`, and the `Vec` is necessary to give away ownership of the files at the appropriate point.
- In the details view, files are now sorted *all* the time, rather than obeying the command-line order. As they're run in parallel, they have no guaranteed order anyway, so we *have* to sort them again. (I'm not sure if this should be the intended behaviour or not!) This means that the `Details` struct has to have the filter *all* the time, not only while recursing, so it's been moved out of the `recurse` field.
- We use `scoped_threadpool` over `threadpool`, a recent addition. It's only safely used on Nightly, which we're using anyway, so that's OK!
- Removed a bunch of out-of-date comments.

This also fixes #77, mainly by accident :)

1 files changed, 1 insertions, 1 deletions

diff --git a/src/dir.rs b/src/dir.rs
index 414ebd3..d7adb09 100644
--- a/src/dir.rs
+++ b/src/dir.rs
@@ -15,7 +15,7 @@ use file::{File, fields};
 /// accordingly. (See `File#get_source_files`)
 pub struct Dir {
     contents: Vec<PathBuf>,
-    path: PathBuf,
+    pub path: PathBuf,
     git: Option<Git>,
 }