Hard-coded build workflow
-------------------------
Currently in AutoBuild, the flow of events is hard-coded in a single file -
AutoBuild.pm.  This flow is roughly:
 * read in configuration
 * obtain lock file or exit
 * create directories / setup environment
 * check out source code from repositories
 * clean old package directories
 * clean build root(s)
 * build each module and record its artifacts
 * run each output module
 * release lock file

There are two problems with this approach.  First, AutoBuild.pm becomes large
and cluttered.  Second, and more significantly, there is no easy way to change
the workflow.  For example, if you wanted to add a notification service that
sent out email before the builds started, you would have to hack AutoBuild.pm.
In a sense, Output modules address this problem in that they let you add
arbitrary functionality, but you have little power in deciding when they are
run, and they must act in isolation from other modules.

Dan Berrange <berrange@redhat.com> came up with the idea of generic stages.  A
stage would be any set of actions that are performed as part of the AutoBuild
process.  The set of stages and their configurations would be configurable on a
per-instance basis of AutoBuild.  This would give administrators much more
flexibility in how/when/which actions are performed.

There would be a set of properties shared by any stage instance.  For example,
each stage would have a run() method which return success or failure[0].
Additionally, each stage would be marked as critical or non-critical.  The
distinction is that a critical stage failing will cause AutoBuild to stop, while
it will continue to run despite a non-critical stage failing.

Another possible property common to stages is dependencies.  However, it is not
clear that explicit dependencies would be better than just using the order of
the stages as listed in the configuration.

The refactoring of the current AutoBuild code to use this concept of stages
would be relatively straight-forward.  A number of the existing classes
(i.e. repositories and output modules) would be ported to be stages.  Also, the
logic in AutoBuild.pm would be split out into new stage classes, probably
corresponding very closely to the steps that were listed above.
