(Release 4.1.0) Bump version
(Release 4.1.0) Remove shrinkwrap
Ensuring that the same mail doesn't get sent to the same user twice

Disclaimer: This is a stop-gap measure until email aggregation lands.

The email API will now try to get a lock (in Redis) each time it tries to send an e-mail.
It will lock on either:
 * a new optional field called `id`
 * if left unspecified it will lock on: mail headers (to + subject + txt body + html body)

This has a couple of effects:

1. Mass-emails on broken activity router
Although it's unlikely that the activity router gets stuck again, the mass flood of emails
is too annoying/upsetting to even have it as a remote possibility.
If it evers gets stuck in a loop on a particular seed again, it will no longer send out multiple emails for the entities involved in that activity

2. For activities the mail id = `to + activity.type + activity.published`
For activities that are generated in very quick succession, some emails might never get sent.
Imagine the following situation:
Alice uploads 50 content items and shares them (in the create request) with bob
If the files are small enough that 2 `content-create` activities get generated in the same millisecond there will be an identical mail ID for 2 activities.
This seems very unlikely, but it is a possibility
#759 PR followup

 * Renamed opts.id to opts.hash in the sendEmail API
 * Various code/jsdoc cleanup
Pull in fix for buffer overwrite in amqp module
Use git:// for package.json github reference
Merge pull request #761 from mrvisser/amqp-0.1.8.x

Pull in fix for buffer overwrite in amqp module
email hashing - PR followup - cleaned up jsdoc
Merge branch 'email-hash' of https://github.com/simong/Hilary into email-hash
Fixed typo