This is designed to handle the case where we want:
* The pipeline to be triggered by changes so results report back to
the change.
* Triggered on change merged.
* Jobs with file matchers so that if a subsystem is changed, only the
deployment job for that subsystem is run.
* Every change is processed in strict sequence.
This is designed to accomodate a deployment pipeline with the above
constraints.
The pipeline manager hierarchy is getting complicated; mark the base
class as abstract, and also move the shared-queue methods into an
intermediate abstract class. These are shared by both serial and
dependent managers.
Change-Id: I3c5f3b2f6298292c5c25665923e3a10b07be5419
22640baef4