Add concurrency to queue-run

Saving a reply from greg.1.anderson into this issue about http://dominiquedecooman.com/blog/drupal-7-tip-concurrent-indexing-searc...

I noticed two minor defects in the code in the article.

1. It places a space in the command name; it uses 'command' => 'queue-run
' when it should use 'command' => 'queue-run', 'args' =>
array('').

2. It forks too many processes. It creates one command per item in the
queue; it only needs to create N commands, where N == the concurrency
level, as each queue-run command that is forked will try to process all of
the items in the queue. By the time any one of these exits, there will be
no items for the remaining Q - N processes to process. (Also, I suspect it
does not need to fill $invocations with the same command N times; I think
Mark had a mode where the same command could be run N times, for the xprof
code, but I don't see it anymore -- not sure if that's gone, or if I just
missed it.)

Those minor defects do not detract much from the awesomeness of the hack.
I think it would be a good idea to include this feature in Drush core.
`drush queue-run` with concurrency > 1 could use
drush_backend_invoke_concurrent to call `drush queue-run` with a concurency
of 1 (which would cause the usual code to run) -- a little dirty, but would
work. Alternately, the current implementation of queue-run could be
renamed to queue-run-one, and the new queue-run could call queue-run-one,
either directly with drush_invoke (concurrency == 1), or with
drush_invoke_concurrent for concurrency > 1. I think I favor the later
implementation; slightly more work, but cleaner.

Now I'm thinking I should have put this in an issue. :p Don't really
have time to do it right now, although most of the effort is in the test
code. If someone wrote a failing test, I'd fill in the real code in a sec.
:) Don't need it myself right now, but the cool factor is appealing.