... such that it fetch all dependency status using SMEMBERS and HGET rather than SORT.

* Add the queue to the queues set when scheduling a job

* Fix the registry properties docstrings

* Rename `dependent_jobs` to `jobs_to_enqueue` in queue.py
* Rename `dependencies_job_ids` to `dependency_ids`.
* Remove `as_text` (no more python2 support). Use `bytes.decode`

...to `exclude_job_id`. Also make it a single id not a set.

When a job with dependents is _successful_ it's dependents are enqueued. Only if the FINISHing job's `result_ttl` is non-zero is the change in status persisted in Redis - that is, when each dependent job is enqueued, the _FINISHing_ job (,triggering the enqueueing,) has an _outdated_ status in redis. This avoids redundant call because if `result_ttl=0` then the job is deleted then deleted in `Job#cleanup`.

In order to enqueue the dependents, we therefore _exclude_ the FINISHing job from the check if each dependents' dependencies have been met.

Convert method on Job to return a boolean and rename. Also use
fetch_many in Queue#enqueue_dependents.

Method Queue#enqueue_dependents checks the status of all dependencies of all dependents, and enqueues those dependents for which all dependencies are FINISHED.

The enqueue_dependents method WAS called from Worker#handle_job_success called BEFORE the status of the successful job was set in Redis, so enqueue_dependents explicitly excluded the _successful_ job from interrogation of dependency statuses as the it would never be true in the existing code path, but it was assumed that this would be final status after the current pipeline was executed.

This commit changes Worker#handle_job_success so that it persists the status of the successful job to Redis, everytime a job completes(not only if it has a ttl) and does so before enqueue_dependents is called. This allows for enqueue_dependents to be less reliant on the out of band state of the current _successful job being handled_.