Allow job ID to be set on enqueue/enqueue_call() - fixes #412

Fixes #412.

Includes unit tests and is backwards compatible. 

There is a small/minimal risk to enqueue(), for anyone already passing `job_id` as a custom task attribute when calling enqueue(), as it is treated with the same "specialness" as `result_ttl", e.g. it is popped off the `kwargs`.  This is an unlikely edge case, but let me know if you think this is unacceptable.

There is no risk for enqueue_call().
Yeah, please us `id`, thanks :)


Win~


On Sat, Sep 6, 2014 at 1:31 AM, Cal Leeming <notifications@github.com>
wrote:

> In rq/job.py:
>
> > @@ -92,7 +93,8 @@ class Job(object):
> >      # Job construction
> >      @classmethod
> >      def create(cls, func, args=None, kwargs=None, connection=None,
> > -               result_ttl=None, status=None, description=None, depends_on=None, timeout=None):
> > +               result_ttl=None, status=None, description=None, depends_on=None, timeout=None,
> > +               job_id=None):
>
> The problem with using attribute id in method args, is that it collides
> with builtin id(). Are you happy to overwrite local scope for that
> builtin? If so I'll update the PR, let me know.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/nvie/rq/pull/415/files#r17189250>.
>