Unifies how jobs are executed into Processor.

Yay! removed code!

A while back I submitted [a PR](https://github.com/mperham/sidekiq/pull/1938) that exposed a way to customize how a job was executed, in so much as how perform was actually called on the worker. I duplicated that in the sidekiq/testing, and have since determined that was a mistake and am rectifying that here.

In doing what I talk about in that original PR, I realized there was still some finagling to get it to behave correctly for the specs, and then I realized that it wasn't very unified and didn't push through to the actual functionality that I wanted to make sure was working -- in this case, that my override was properly behaving in various scenarios.

While I was in there, I simplified the `drain` method as well. Hopefully this cleans up and makes my objective a little more clear.

If you want more background, I'm happy to provide it, but basically it boils down to this working cleanly, and consistently now.. also, less code. =)

```ruby
class Sidekiq::Processor
  def execute_job(worker, cloned_args)
    if worker.respond_to?(:call)
      worker.call(cloned_args[0]) # named arguments way
    else
      worker.perform(*cloned_args) # standard way
    end
  end
end
```
The alternative that I saw while I was doing this, would be to make execute job a broader concept. Since it takes the worker, and args, there's no reason it needs to be an instance method on Processor, or even within it. It could be pulled to the class level, or really, placed anywhere -- on the Base module or wherever?