Attempting to move to using Fog::XML::SAXParserConnection directly
failed because the arguments changed.
This adds another compatibility level with two key differences:
1) It's namespaced within XML so stands out as not being part of core
2) It is NOT creating deprecation warnings so can be used as the final
step if rewriting to use SAXParserConnection is undesired
So when merged Fog::Connection usage will create noise.
Fog::XML::Connection works the same way and will be extracted to
"fog/xml" when we get to it.
Fog::Core::Connection just wraps Excon.request and leaves the response
body parsing to the provider.
This creates a new `Fog::Core::Connection` class that wraps around HTTP
connections/requests but does not presume SAX parsing of the API response.
A new `Fog::XML::SAXParserConnection` is available which implements the
original behaviour with a clearer interface.
`Fog::Connection` subclasses `SAXParserConnection` to be backwards
compatible.
Further testing and deprecation warnings are needed.
Since mock testing occurs at a higher level the changed code is not
exercised by the tests and I do not have access to an XML based API to
debug quickly with.
Rather than embedding XML and JSON support within fog-core, this is the
start of extracting them to exist alongside core.
That will move the responsibility to each provider to declare if they want
XML or JSON services.
Goal being as we move towards a modular fog this allows providers to
require core and either JSON or XML gems and not pick up dependencies
only required by the other.
