Refactoring to remove most knowledge of Redis out of the Resque::Worker....

... In general, trying to cut down on the number of methods in Resque::Worker and the responsibilities it has (i.e., it currently (1) gets jobs, (2) does work, (3) can tell you information about other workers on the system, (4) gets statistics from Redis, (5) acts as a Factory to find workers that are working or find a single worker, etc.)

--

Some of the classes you might want to rename or we can keep refactoring, but my goals were to cut down the responsibility of Resque::Worker:

1. Moved most communication with Redis to a WorkerRegistry; the registry is responsible for updating all statuses in Redis (registering, unregistering, updating job status, done working, etc.)
2. Started shifting methods in Resque::Worker from being 100% public to split out into protected. I think that creating subclasses on Resque::Worker for variety of Worker types (e.g., forks, doesn't fork, uses threads, etc.) will ultimately be the way to extend this. Looking at [Sidekiq's internals](https://github.com/mperham/sidekiq/wiki/Internals), having a "Fetcher" which pulls messages off the queues and ultimately passing that down to a "Processor" which runs them seems like a good abstraction. I think that's a good direction to consider and head toward.
    * In general, I think that Resque's interface is already somewhat confusing: there are multiple ways to do the same thing (e.g., "Resque.working" vs "Resque::Worker.working" -- good interface design should make it clear when/why you'd want to use a certain method. Method aliasing seems okay for backwards compatibility but not good for a fresh, clean interface, especially across classes. I think that functions like `Resque.working` should be removed for interface consolidation.
3. Creates a ProcessCoordinator class to answer questions about Resque processes running. I'm not a big fan of this class name but I think it should definitely not be in `Resque::Worker` since it's a different responsibility. It's more of a utility so not really a coordinator (I was originally going to centralize some of the forking and Process.kill'ing logic and behavior into it, but getting the pid methods out seemed like the simplest way to reduce complexity)

I was thinking about abstracting out the statistics as well but that's already fairly isolated and simple with a counter system. However, I think it's eventually something good to do to centralize magic strings.