Allow objects to bypass Service's global config

[tokengeek]

Up to now you had to accept that if ~/.fog exists on a system that
it's values were likely to be merged into any service by the reference
to Fog.credentials.

One solution was to load your own credentials and pass the settings
through to services. However the cleaning of the Hash still merged the
settings with the global and created a new Hash.

This also encouraged each service to do it's own authentication
internally by passing in values like username and password then
requesting a token that was isolated to that service.

That made it unsuitable for passing one configuration object that is
shared between multiple services where both may want to change something
such as the latest, valid authentication token.

This change allows any object that responds to config_service? with
true to bypass the global merging, parsing, coercion etc. and be
passed directly to a service.

That allows services to dispense with primitive obsession and use tested
objects to configure their services.

Resolves fog/fog#1390

[tokengeek]

@geemus This is the backwards compatible implementation of the discussion on fog/fog#1390

You can use everything as normal and it should work fine.

However if you pass an object the responds true to #config_service? then it gets passed through untouched to the services. Given the double complexity it's very much opt-in.

I have a Fog::Brightbox::Config object I'm finalising that is now working within our compute service and I believe completely avoids Fog.credentials.

If I pass in a blank config with FOG_RC the only failure I can trigger is the case where you are falling back on the default behaviour and Fog.credentials is getting called.

[tokengeek]

Errors were due to declaring a lambda in line phasing Ruby 1.8.7

[geemus]

Thanks!