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
```
You're right, Processor is under-tested because of its design: it's the integration piece that ties a bunch of much simpler objects and makes them concurrent.  I'm not convinced removing 10 lines of test helper code is worth poking that bee's nest.