`ActiveJob::Base#queue_adapter` can now accept a callable

This allows for the determination of a Job's adapter at runtime.

Consider the case of a migration from Resque to Sidekiq. The migration
is a state machine; on a large deployment and in the absence of this
functionality the state machine has the following states:

| Exists                | Running                    |
| --------------------- | -------------------------- |
| FooJob(R)             | FooJob(R)                  |
| FooJob(R),FooJobSK(S) | FooJob(R)   -> FooJobSK(S) |
| FooJob(S),FooJobSK(S) | FooJobSK(S) -> FooJob(S)   |

In order to ensure the process is safe (no jobs are ever lost), we need
2 deploys. Note that to implment the runtime transitions above the user
must build their own abstraction layer on top of AJ which can
provide dynamic adjustment of target queues.

Now consider the equivalent state machine in the presence of this
functionality, with the proc resolving via external configuration (e.g.
redis, the database, zk, etc.):

| Exists                | Running               |
| --------------------- | --------------------- |
| FooJob(R)             | FooJob(R)             |
| FooJob(proc)          | FooJob(R -> S)        |
| FooJob(S)             | FooJob(S)             |

This is almost the same, but does not require the user to implement a
custom abstraction on top of AJ; all the necessary facilities are
provided.