Move the parallel execution code into Runner

[AWhetter]

Currently the code to deal with parallel execution lives inside the PyLinter class. This means that a PyLinter ends up running PyLinters when executing in parallel (via ChildLinters). It also means that a new PyLinter is created every time a file/module is read, and the config object has to be loaded into the new PyLinter instance.

We could eliminate this overhead by getting the Runner to launch threads, have a single PyLinter object per thread, and distribute the work to those threads.

This will also eliminate the need to change the jobs option in the config when passing it to child PyLinters.

[The-Compiler]

It uses subprocessing currently if I remember correctly - is that also your proposal for this change? Because threads will probably not work out due to the python GIL.

[AWhetter]

My proposal is to move the parallel code out of PyLinter, scrap the ChildLinter, and move all of that code into Run. Then Run will spawn a single PyLinter per thread.

It's using multiprocessing rather than subprocessing at the moment. I don't want to change what threading library we use, or change the task queue technique we use at the moment.

[PCManticore]

@AWhetter let's use process instead of thread, so we won't confuse people with what we plan to change.

Sounds like a good idea, but some things might need to be changed. For instance, the configuration needs to be done before starting the jobs, expand_files might need to move and each process needs to take care of loading the necessary plugins (this is currently done before it, through load_plugin_modules).

While we are it, can we rename Run into something else?

[AWhetter]

Implemented via #955