`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(Resque)                    | FooJob(Resque)                   |
| FooJob(Resque),FooJobSK(Sidekiq)  | FooJob(Resque)                   |
| FooJob(Resque),FooJobSK(Sidekiq)  | FooJob(Resque)->FooJobSK(Sidekiq)|
| FooJob(Resque),FooJobSK(Sidekiq)  | FooJobSK(Sidekiq)                |
| FooJob(Sidekiq),FooJobSK(Sidekiq) | FooJobSK(Sidekiq)                |
| FooJob(Sidekiq),FooJobSK(Sidekiq) | FooJob(Sidekiq)                  |
| FooJob(Sidekiq)                   | FooJob(Sidekiq)                  |

In order to ensure the process is safe (no jobs are ever lost), we need
6 deploys. Note that the transition `FooJob(Resque)->FooJobSK(Sidekiq)`
will still need a proc somewhere, just that it won't be hosted by AJ.

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(Resque)                    | FooJob(Resque)                   |
| FooJob(proc)                      | FooJob(Resque->Sidekiq)          |
| FooJob(Sidekiq)                   | FooJob(Sidekiq)                  |

Only 2 deploys are required. Note that the last deploy is optional;
because we can modify the target queue in configuration (rather than
code), we can leave the proc in place indefinitely.