In the context of an "early" release, evaluate whether to revert the Boot2Docker and Docker Machine integration removal

[fabiobrz]

Issue Overview

We might want to release a CR build "early", in order to resume the project status.
In such a context, it could be useful to cut the final changes to the bare minimum, and let replacements happen asynchronously.

Recently, we've merged changes, mostly removing stuff from, the Boot2Docker and Docker Machine integration, being such components deprecated.

This makes sense only if we have a plan for replacement, which ATM doesn't seem to be the case, and anyway an early release should keep the deprecation, changing as less as possible in order to fill the continuity gap, so that migration is smoother.
Solutions for replacing the Boot2Docker and Docker Machine integration can be discussed and implemented asynchronously.

Expected Behaviour

Despite for the components being deprecated, an early-cut release could provide feature parity with the last one available if possible, i.e.:

• provide integration with the Boot2Docker integration, so that Arquillian Cube can run on Wildows and Mac OS.
• Similarly, reverting the Docker Machine removal would allow resuming the containerless tests execution.

Current Behaviour

Arquillian Cube cannot be run on systems that require Boot2Docker, e.g.: Windows and Mac OS, and containerless tests cannot be executed.

Steps To Reproduce

N/A

Additional Information

N/A