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
Let's just use an "attr_reader" for the default implementation (this makes it clear that there is no default-value as well)

```ruby
# @abstract
# The number of seconds to set the TTL to on the resque-retry key in redis
#
# @return [Number] number of seconds
#
# @api public
attr_reader :expire_retry_key_after
```