New Scheduler Driver that adds in caching

I believe we need to encourage more scheduler innovation, by encouraging more scheduler drivers, allowing people to make different tradeoffs. Some of these may be dead ends, but I hope they may spark better ideas, and some may become the default scheduler, if they prove themselves.

This new driver attempts to:
* generate a list of pre-picked scheduler slots
* when user request hits scheduler, attempts to pick cached decision first

The idea is to do most of the expensive work up front, and do some very reduced filtering/weighting of hosts on each user request.

Implementation wise:
* this is a new driver
* uses the existing host manager for filtering and weighting
* will not have all the features of the existing filter scheduler

The current implementation is designed to work well under a low, but predictable load, when the cloud is also got a reasonable amount of space capacity.

Once this initial draft is complete (this blueprint), we can look at further ideas (in a follow up blueprint) to scale out the scheduler to multiple hosts with either:
* shared scheduler cache (centralised)
* pre-commit resources on a specific compute node's resource manager (de-centralised)

For more details, see the full specification document I have recently added.

UPDATE:
Testing showed the slot based cache mostly slowed things down.

The best benefit if from caching the list of hosts. The current filter scheduler is able to do the rest.

If you have a high rate of deletes (and creates), you can get NoValidHost when there is actually space, but at the next poll period the system would be correctly updated. If you are that low on capacity there are likely to be other issues anyways.