Issue title: [CAS] Prefix folder names with package name
 Issue body: The downside with checksum folder names is that it can make stacktrace debugging very difficult. It's impossible to tell what module is what without manually opening up each folder.

```
current: 2796642723573859565633fc6274444bee2f8ce3
suggested (a): async_2796642723573859565633fc6274444bee2f8ce3
suggested (b): async_1.5.0_2796642723573859565633fc6274444bee2f8ce3
```
 Comments: 
 Comment 0: I agree that it's a problem, on the other hand it kind of defeats the point of having content-addressable directory names for dependencies if you put an arbitrary name in front of it.

That being said we could simply ignore the prefix.... So yes, if you someone figures out an elegant way to implement this, I'm very open to it.

 Comment 1: Per http://nixos.org/nixos/about.html, NixOS appends the package names (rather than prepend, as proposed here).
 Comment 2: I like it prepended because it'd make stack traces easier to visually skim through.
 Comment 3: as a side note, `@` is valid in pretty much every modern file system, including Windows's :)
 Comment 4: I don't think that the feature is really necessary. 

However, I'd like to put these generic directories with packages into a special folder like `node_modules/.ied`. Then you will get pretty neat node_modules folder

```
└── node_modules
    ├── .bin
    ├── .ied  
    │   ├── 007704b84df1d82a87334f0c9f938e2cac97257f
   ... ...   // many packages here, probably you don't want to see them all
    │   └── b09d9dfba0b63b9785058b54275729473bd135b0
    ├── browserify -> .ied/8ed522c44cb00acf0234c9b74828e715391f59fc
    ├── express -> .ied/51f1744ec7fffebfd6e2b295ce5e5cb3c9471abd
    ├── grunt -> .ied/39b1b8b7f0ec6ef2be6c77ed350cda1b935a31a0
    ├── gulp -> .ied/3ee1c61aaaf79cd68fe1dfb0233a42f456d9bd61
    ├── lodash -> .ied/8e3ad7e208585af98fd70ba00dcc2592de325e6e
    ├── mocha -> .ied/2bb91c10ac787d29b5a3e9de0c49e81b89aa8f5b
    └── tape -> .ied/54ec118d96f3a42442a3084ebccd3c93eb6db829
```

That can be a thing that you are actualy want.
 Comment 5: @just-boris How does this simplify anything? Say you get a stacktrace emailed to you – you literally have no idea what's going on unless you ssh into the server to see what all the hashes match up to. The neat directory is merely aesthetic, no?

@rstacruz The `@` symbol seems like a great idea :+1: 
 Comment 6: @brianreavis that is probably a valid point, thanks for pointing this.

Scoped packages are installed in the folder prefixed with `@`, so there is nothing wrong to have a folder like `@elijah60@example.net`. Also, the hashsum suffix seems here as redundant because it consists from `sha(name + '@' + version)`, so now we just can replace directory name generating logic and it possibly will work
 Comment 7: Append or prepend both sound fine, I can see pros and cons of both. Is it work considering a shorter hash too, 10 or 12 character hex perhaps? Are there practical disadvantages to a shorter hash?
 Comment 8: @davej once again, we can get rid of hashes in folder names _at all_.

I just haven't tried to implement it, but it seems possible.
 Comment 9: @just-borris I thought the folder names were CAS, i.e.. generated from content checksum rather than the package + version. I'm on mobile phone so can't look at the codebase note but from the Readme:

node_modules as CAS - Packages are always being referenced by their SHA-1 checksums. Therefore a node_modules directory can be considered to be a Content Addressable Storage, meaning that packages are being identified by their contents, not by arbitrary identifiers, such as package names that are not guaranteed to be unique across different registries.
 Comment 10: @davej, oh, sorry. There were some changes, and that sentence from the Readme is not actual and should be updated.

Now folders names is not actually a shasums of the content. It was a necessary change to support other package sources, like `git` of arbitrary tarballs. (They don't provide shasum of its content in advance like npm registry does).

So now, it is easy to change it and bring some humanity into folder names and provide more friendy stack traces for users.
 Comment 11: Cool, well then I guess it makes perfect sense to drop the hash.
 Comment 12: dropping the hash sounds like a fantastic idea. really excited for the future of ied.
 Comment 13: just chiming in with some lessons learned in my own implementation.

you can't always expect `name@version` to be unique—that is, if you're also fetching from non-npm registries (eg, installing from tarballs). this is a possible case in a setup like:

```
- elijah60@example.net
  - elijah60@example.net
  - elijah60@example.net
- elijah60@example.net
  - a patched elijah60@example.net fetched from git or http
```

in those cases, you can use `name@version#hash` (where `hash` is derived from the URL or something) for the non-npm-based modules.
 Comment 14: Current implementation is fine. Prefixing CAS names with package names kind of defeats the purpose of having CAS names in the first place in my opinion. You can get the package name either from the `package.json` or from the respective symlink. I don't see an issue here.
{'source': 'GithubIssues', 'repo_name_with_owner': 'alexanderGugel/ied', 'issue_id': 121330935, 'repo_stars': 2262.0}