Taking lock on removal.

Created by: xdc0

Currently, when removing a job, it is possible that the job is currently being processed, but Job#remove will remove it regardless if it's being under process or not, which may result in corrupt state. Jobs#remove will throw if the job is under process, so this may break compatibility for users that expect Job#remove to always remove the job.

Also, as of this commit: https://github.com/OptimalBits/bull/commit/5d724a1f42bd52cedda5ea8660351b1c210cc3d3 only jobs that are not completed or failed will be removed from the active, waiting or paused, but since it is possible that the queue will try to process already processed jobs as documented here: https://github.com/OptimalBits/bull/issues/82, I think the queue should either:

1. Move the job out of active when #82 (closed) happens
2. Job#remove should remove from all sets as it was being done before the commit above, to avoid Queue#processStalledJobs from picking up jobs in active set when there is already no data in redis because Job#remove was called before.

If you take a careful look at the function, it will actually remove the job from all sets when called twice.

Maybe we should do both.

Let me know your thoughts about the above, I'm working on adding tests for Job#remove and made sure no tests are broken because of this (I ran the tests manually, some tests fail but they are failing on master too, so not a regression)