Providers listing is no longer stored in lists, it's now driver dict based.
Updated `is_provider_configured` to look for data in the new dict based providers config.
Minor typo.
Let us know what's going on when an exception happens on parallel querying nodes.
Pass current opts dictionary to `vm_profiles_config` and `cloud_providers_config`. This will help unifying profiles with providers.
ALL configuration parsing, merging and unification is now done in `saltcloud.config`.
One step further. Refs #546

* All cloud profile now has it's provider set as `<alias>:<driver>`. This is done when loading the configuration.
* All cloud providers settings now include a `profiles` key for each of it's driver which included every profile that is using the `<alias>:<driver>`. This is done when loading the configuration.
* Cloud profiles are no longer stored as `vm` in the internal configuration dictionary. It's `profiles` now.
* Fixed the `ec2` driver because of how the data is laid out now.
* Fixed the `get_config_value` config helper, also because of how data is laid out now.
`saltcloud.cloud.Cloud.get_provider()` is no longer necessary.
Since we now enforce a specific data layout, `get_configured_providers()` is now simplified.
Removed `saltcloud.cloud.Cloud.get_providers()`.

There no more need for the above method since we iterate through our mapped configuration data and act accordingly.
We now also output the data queries like `<provider-alias> -> <provider-driver> -> <queried-data>`.
Depend on salt >= 0.16.0
In order to call a function for a driver, one must now use the profile name, not the driver name.

If there are multiple drivers defined under the same profile, and the driver is not specified, the user is warned and salt-cloud exits.
Fix bad reference to renamed variable.
Removed `get_matching_provider()` was not necessary.

For that, `do_function()` needed to be fixed/adapted to use `build_lookup()`. Data is returned as `<provider-alias> -> <provider-driver> -> <returned-data>`.
Some context black magic to solve some problems.

Instead of changing most of the cloud driver functions arguments to accept either the `vm_` argument or the current profile name, let's play with injecting the current profile name, which will be required, into python's `__builtin__`. As soon as done, we clear the built-ins.
Don't define extra built-ins, define module globals.

In order to use our active provider context manager, we were previously defining an extra built-in. That built-in, as all built-ins would be available to the python interpreter. We just need to define and update a module level global.
After leaving the context manager scope, the previous value is reset.
Both `do_function` and `do_profile` now make use of the provider context.
Add comments to why we're not using `CloudProviderContext`.
CloudStack is now aware of the `__active_profile_name__` context variable. Refs #546. PEP-8 + Indentation + Formatting
Digital Ocean is now aware of the `__active_profile_name__` context variable. Refs #546