Deprecate `engine_conf` and prefer `engine` instead

To avoid having one set of options coming from `engine_conf`
and another set of options coming from `kwargs` and another set
coming from `engine_conf` if it is a URI just start to shift
toward `engine_conf` being deprecated and `engine` being a string
type only (or a URI with additional query parameters) and having
any additional **kwargs that are provided just get merged into the
final engine options.

This adds a new helper function that handles all these various
options and adds in a keyword argument `engine` that will be shifted
to in a future version (in that future version we can also then
remove the `engine_conf` and just stick to a smaller set of option
mechanisms).

It also adjusts all examples to use this new and more easier to
understand format and adjusts tests, conductor interface to use
this new more easily understandable style of getting an engine.

Change-Id: Ic7617057338e0c63775cf38a24643cff6e454950
Use and verify event and latch wait() return using timeouts

Instead of blocking up the whole test suite when a latch or
event was not decremented to its desired value (or not set for
an event) we should use a reasonably high value that we use
when waiting for those actions to occur and verify that when those
wait() functions return that we have reached the desired state and
if not either raise an exception or stop further testing.

Fixes bug 1363739

Change-Id: I8b40282ac2db9cabd48b0b65c8a2a49610d77c4f
Merge "Deprecate `engine_conf` and prefer `engine` instead"
Merge "Use and verify event and latch wait() return using timeouts"
Add a futures type that can unify our future functionality

Move the currently existing green future executor and associated
code to a new futures types module so that it can be accessed from
this new location (TODO: deprecate the old location and link the
old to the new for one release so that we can remove the old link
in N + 1 release).

This unifies the API that the existing pool (thread or process) future
executors and the green thread pool future executor, and the newly added
synchronous executor (replacing the previous `make_completed_future`
function) provide so there usage is as seamless as possible.

Part of blueprint top-level-types

Change-Id: Ie5500eaa7f4425edb604b2dd13a15f82909a673b