Lock Improvements

This code goes along with #128

It refactors how `Rufus::Scheduler` handles locks (no more need for subclasses!), but more importantly it allows multiple schedulers to run concurrently, with only one of them running jobs at any given time.

Additionally, this fixes a seeming bug with `JobArray#delete_unscheduled`. A job's `@next_time` value can be `nil` or `false` if it never intends to run again, but we only checked for a `nil` value. With the fix, jobs that are scheduled using `scheduled_in`, for example, will get pruned.
Ah, that makes sense.

My example is what happens when `confirm_lock` returns `true`, so the job triggers but it doesn't run its block:

```ruby
callable = proc { }
scheduler = Rufus::Scheduler.new

def scheduler.confirm_lock
  false
end

job = scheduler.schedule_in(0, callable)

sleep 1

job.next_time # => false

def scheduler.confirm_lock
  true
end

# job is still not run, but stays in scheduler.jobs
```

So my question: what does it mean when `@next_time` is `false`? Doesn't seem like the job is ever run.