Refactor the local engine to use an in process executor

Currently, the local engine runs the task immediately whereas the scalable engine sends it over the message queue to one or more executors. Mistral user will typically use the local engine for exploration, testing, or demonstration purposes. The proposal here is to move the abstraction to the executor instead, having drivers for a local executor and remote executor. The message flow from the engine to the executor would be consistent, it would just be where the request will be processed. Since we are already porting to oslo.messaging, there's already a fake driver
that allows for an in process Queue for local execution. The propose change involves collapsing the local and scalable engine to a single engine. The unified engine will dispatch the task request to a executor. Whether the executor is an in process one vs. remotely behind an actual message bus will be configurable per oslo.messaging rpc backend. Please refer to the mailing list entry @ http://lists.openstack.org/pipermail/openstack-dev/2014-February/028010.html for the group discussion.