Integrate ActiveJob / DeliverLater / GlobalID with Rails

WIP.
> Yes, retry would have the same behavior. But which of these might look like there's an infinite loop?

If we're leaving in the `rescue_from` block, I think it's about equal, with `rescue error` one line away from the retry action and just a couple more from the culprit code.
```ruby
rescue_from(ArgumentError) do
  retry_now
end

def perform(name)
  my_helper # oops! I forgot the arg
end
```

Both examples are kind of dumb though, because you'd never rescue `ArgumentError` and retry. In actual non-test jobs, the developer has made the conscious decision the error they're explicitly rescuing from can be safely retried, so an "accidental infinite loop" seems very unlikely to sneak in.

> Surely rescuing some particular exception can't have the same logic for every single method in your object.

Good point. I was working under the assumption a job would only have a single `#perform` method (like most of mine do) and no other methods, so very much like controller actions. In that case `rescue_from` makes sense, but less so in the situation you describe. 

I don't think I'm alone in preferring simple jobs with a `#perform` that doesn't do much more than calling a handful of methods on another class or a provided model, so I would really like to keep `rescue_from` in with easy rescuing from `ActiveRecord::RecordNotFound`, but of course this still leaves people with more complex jobs (like you) free to inherit and call super from `execute`.