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
I'd like to see this broken out a bit, this is what I had in mind:

```ruby
# set/update the "retry_key" expiration
if expire_retry_key_after
  log_message "updating expiration for retry key: #{retry_key}", args
  Resque.redis.expire(retry_key, retry_delay + expire_retry_key_after)
end
```
... Also, I believe the `to_i` calls are unnecessary