Sha256 custom

Crypto is moved outside of peerlibrary, into separate package named sha256. Digest package is removed, it's available only within sha256 package, no longer in global scope. It was required to add digest.js as an asset so it can be used by web Worker. Only Crypto object is available in global scope. Its usage and behavior on server is unchanged. On client, ```update``` and ```finalize``` methods take callbacks. API is explained in comments, see ```packages/sha256/client/crypto.coffee``` . Otherwise API remains the same (```update```, ```finalize```) but ```destroy``` method is added to be able to terminate web worker.
Internally, it makes some initial checks to determine browser's features. Constructor fails with exception if ```ArrayBuffer``` is not supported, but in that case application will probably fail much earlier.
It will use ```Worker``` if possible, or fallback in main thread. It's important to note that there is no difference in behavior visible from outside.
From outside, you can tell if objects should be transferred to Worker or not (which basically means, do you need them afterwards or not).
```update``` can take ```File```, ```Blob``` or ```ArrayBuffer``` objects.
```onProgress``` callback should be assigned on each ```update``` call and it returns progress as ```float``` relative to the chunk given in the update. That means if you send chunk by chunk, progress will hit 1 (100%) for each chunk so you have to calculate actual progress outside. But there is no reason not to send the whole byte stream at once (if you already have it in main thread). It will be split in chunks internally, one by one, to keep the memory low. Giving chunks only makes sense if we get chunks from other thread. For example, if we could get only a chunk from pdf.js worker thread, then we never have load the whole stream in memory. So, if pdf.js adds that support, or we decide to patch it, it is supported and it will be possible to calculate the actual (absolute) progress of computing hash.
I decided not to patch pdf.js at this point. It would be ugly (with monkey patching or without) and it would have to be used synchronously (to make sure there is always only one chunk in memory). Since peerlibrary is heavily under development, I don't feel it's time to do such things.