(MCOP-20) Correctly honor concurrency argument of runall

In the past there existed a race condition that could be triggered when
a Puppet run was slow to get into what is defined as its "applying"
state. By defining "applying" as the existence of the run lockfile we
were ignoring the case where the agent action has triggered but the
lockfile hasn't been created yet.

This commits extends the meaning of applying by including the "signaled but
not yet started" state. This is implemented by adding an :initiated_at output
field to the agent's runonce action which can then be used to check
against the value of lastrun returned from a status action. If the
value of lastrun is less than the value of initiated_at and applying
is false we can determine that the a run has been triggered but it hasn't
started yet.

Note that in the case where communication with a Puppet Master was
broken this could lead to a situation where a node is identified as
applying (signaled but not net applying state) and never leaves. Because of this
we allow a node 5 state checks (~5 seconds) to leave this state before
removing it from the run list and logging a failure.

This improvement means that the previous behaviour of including nodes
started outside of our control when determining how many nodes to start is
kept while also removing the race condition. The race condition can
however still exist in environments where different versions of the
agent is present at the same time but these kinds of environments are
not recommened.
Merge pull request #24 from ploubser/bug/master/mcop-20

(MCOP-20) Correctly honor concurrency argument of runall