Make node provisioning strategy plugable
Clarify the lock semantics
Narrow the scope of lock required to get the pending nodes.

- Too many things have incorrect locking assumptions on calling NodeProvisioner#getPendingLaunches()
- Simpler to narrow the lock requirements as that should prevent deadlocks
- We now only need the lock for a very short window and the lock is only on the list of pending launches.
typos
Fix syntax in Javadoc comment
Tidy up javadoc some more
Merge pull request #1433 from stephenc/master

Refactor NodeProvisioner to allow for extension of strategies
fix @since tags
Prevent a storm of node monitor updates when there is a storm of nodes coming on line within 1 second

- The old code would result in multiple triggered updates, with corresponding interrupts of in-progress updates
  when faced with lots of slaves coming on line within 1 second of each other.

- New code will ensure that one and only one of the scheduled tasks (i.e. the last one) will trigger the updates.
If you are synchronizing on something to access a volatile, then you are doing something wrong

- Yet more interrupting bad patterns, especially where we expect the node monitor to take up to 30 seconds to complete if an async variety