Allow clouds to launch slaves with job-specified parameters

We would like to be able to add parameters into a build to contain
a setting for various slave parameters - for example, a docker volume
that contains a Jenkins workspace.

This would enable that workspace to be 'passed up' through a build pipeline
to subsequent stages.

However - with the current API, there is no way of the slave launcher
knowing what additional slave startup parameters that it needs. By the
time the slave is constructed, this is too late - such settings can only
be applied at slave construction time.

Thus there is a need for the slave launcher to be aware of (optional)
parameters that it can use in order to control the slave that it is
launching.

So -

- create a new CloudProvisioningRequest object, that contains the existing
settings (Label, Excess Workload), and a list of 'Actionable' items that
it is passed. Add a provision option into the Cloud class (default impl
for backwards compatibility to be the old provision impl).

These Actionable items are, in effect, the builds in the queue. The cloud
subclass can examine this queue and pull off builds. From there it would
look for the ParametersAction, and the Parameters stored within. Cloud
implementations will provide their own ParameterDefinition/Values that
they look for.

Once a slave is launched, we need to make sure the 'right' job is attached
to the 'right' slave. Fortunately, all a cloud implementation needs to do
is add a NodeProperty to the launched slave, which Jenkins will ask
'canTake' to see if a buildable item is appropriate for this slave. All
the slave then needs to do is say it's not appropriate for that node if
the launch parameters don't match the build parameters.

Signed-off-by: Nigel Magnay <nigel.magnay@gmail.com>
I'm easy, but if it's Collection<Queue.Item> then that class 'leaks' to the downstream consumers. They only care about the Actionable in the queue (to get the properties out), not the queue itself. Keeping it more abstract means they're not fragile if there's ever rework inside queue management.