Ivy refactoring - step 2

[Xavier Hanin <xa...@gmail.com>]

Hi All,

I've made some progress in the refactoring, and checked in the changes
so that you can follow my progression. Each time I commit progression,
all the unit tests are passing, but I don't make more tests.

At this step I've begun to split the Ivy class. I've extracted an
IvySettings class, which stores all settings, i.e. the result of a
call to configure. I've tried to replace some dependencies on the Ivy
class by dependencies on IvySettings, when it was possible, to attempt
to remove some circular dependencies.

For instance:
Ivy -> ModuleDescriptorParser -> Ivy
 is now
Ivy -> ModuleDescriptorParser -> IvySettings

I've also extracted a class ResolveEngine, which is responsible of the
resolve algorithm. Hence the Ivy class has slimmed, but I still have
to extract other parts (retrieve, install, ...) so that it will only
be a Facade to other engines/services.

One thing which has changed due to this split is the way an Ivy
instance is obtained. For the moment when you use a 'new', the
instance created does not create its dependencies (instance of
IvySettings and ResolveEngine for example). The idea is to make it
possible to use other implementations (well, subclasses, since they
are not interfaces) instead of the implementation provided by Ivy, to
be able to fully customize the behaviour of Ivy by feature. So the
creation of dependencies is only done in method I've called 'bind'. If
you want an instance of Ivy already bound to its dependencies, you can
use Ivy.newInstance(). If you prefer to setup the dependencies
yourself, you can call 'new Ivy()' and then setters for the
dependencies. Note that binding is automatically done when you call a
method on Ivy which require a dependency, so that you don't have to
care about that in most cases.

Feel free to send feedback on this progress, on my side I'll continue
the split the Ivy class and review the API.

Xavier