drop multiprocess, use xmlrpc multicalls instead
    
    I'm kinda in two minds about this. On the one hand, multiprocess
    is definitely faster. On the other hand, this is less voodooish.
    
    What this does is use the xmlrpc 'multicall' feature to do
    multiple Koji API queries, instead of running several queries
    in parallel with multiprocess. 'multicall' lets you batch a
    set of API operations and send them all in one request, you
    get the results as an iterator.
    
    I honestly expected it to be faster, but in fact it falls
    between multiprocess and 'do everything one at a time'. I do
    prefer avoiding multiprocess where feasible, though.
    
    This is implemented in slightly tricksy ways to avoid changing
    method signatures. The 'obvious' thing to do is use 'methods'
    arguments, but because that'd change all the signatures, we
    instead allow the 'method' entry in the 'opts' dict to be an
    iterable, and have the Koji client's find_nightly_tasks()
    method handle it. Similarly, find_task_images() and find_
    task_urls() now accept either a single task or an iterable of
    tasks, and their signatures aren't changed (even though it'd
    now be a bit more sensible to use 'tasks' instead of 'task').