Use the module to load from the ncm-module field

Allow to choose the Perl module to run for a given path in
/software/components.

The semantics will be as follows:

For a component defined in "/software/components/foo", if "ncm-module"
exists, that indicates the name of the component to run, so:

"/software/components/foo/ncm-module" = "bar";

will cause NCM::Component::bar to be executed.

If the subpath ncm-module doesn't exist, we'll follow the old behaviour
and run NCM::Component::foo.
Indent properly
Minor code cleanups.

The code is still UGLY.  But this brings no semantic changes and thus no
tests are needed.
Test the _initialize method of ComponentProxy
Store the module to run with the component proxy

This allows us to dissociate the component name from the module it
actually executes.
Load the module and not the component name

Finishes the dissociation between name in the path and module to be
loaded.

Please remember that the loaded module must receive its configuration
path by calling $self->prefix() and using that return value.  Any
hardcoded configuration paths will break this approach.
Add an accessor for the MODULE field.
Load the Perl module specified in the profile

Use the MODULE field for choosing the Perl module to load.
Use the NAME field for the prefix

Last step to dissociate the name of a component from its path in the profile.
Use the declared module as the file associated to the component.
Validate the module name
Add simple tests for the _getComponents method.

This method needs heavy refactoring.  Let's start by identifying and
fixing its behaviour.
Turn autodeps and allowbrokencomponents into boolean options

For consistency with the other options.
Test dependency resolution among components.
Refactor _getComponents and executeConfigComponents

They had became ugly spaghetti code blobs.
Cosmetic change
Remove unneeded cluck
Improve gitignore
Test the run_all_components method
Test and fix bug in component skipping.