allow setting the expire_retry_key_after value on the fly

hey @lantins, @jzaleski

I found an issue in how we handle the expire retry key after value. The problem is that if you have a backoff period where some of the backoff values are larger than whatever default value you set your expiry to, you can end up in a situation where your job will lose its retry key from redis before it gets to retry.

My initial solution was to simply make sure that expire_retry_key_after is always set to backoff_strategy.sum + 1.hour in our implementation, like this:

```
@backoff_strategy = [1.minutes, 1.hour, 1.day]
@expire_retry_key_after = @backoff_strategy.sum + 1.hour
```

The problem with this is that somebody who doesnt know the internals can come along and create a job where they set the backoff strategy to something custom but never update the expire_retry_key_after value. So I decided it would make sense for expire_retry_key_after to be boxed into a function that I can just override in my template like this:

```
def expire_retry_key_after
  backoff_strategy.sum + 1.hour
end
```

thoughts?

cc @camilo
Just a minor formatting comment on this one.. I think it reads a little better

```ruby
def test_expire_key_setting_on_the_fly
  retry_key = 'resque-retry:FailFiveTimesWithCustomExpiryJob'

  Resque.redis.expects(:expire).
    with(retry_key, 100).then.
    with(retry_key, 101).then.
    with(retry_key, 102).then.
    with(retry_key, 103).then.
    with(retry_key, 104)

  Resque.enqueue(FailFiveTimesWithCustomExpiryJob)
  5.times do
    perform_next_job(@worker)
  end
end