An analysis of the MooseTask hierarchy

here are some notes we wrote when browsing the MooseTask

- It would be good to rename MooseTask should be renamed because it has nothing to do in Moose.t 

- MooseTask and MooseOperator should be in the same package: Moose-Core since MooseOperator has nothing to do with Smalltalk.

- the hierarchy of MooseCompositeImporterTask is really dealing only with Smalltalk importing logic.

so we should rename it:

SmalltalkCompositeExtractorTask or at least SmalltalkCompositeImporterTaskcolle

- MooseImportClassesTask should be renamed SmalltalkImportClassesTask  or SmalltalkExtractClassesTask

since it only create entity extracted from Smalltalk. 

( Importer vs extractor

I would like to keep the term importer to the action of populating a model and the action to extract model from source code.

In java, c3 we have extractor and in Moose importers and extractors)

- I would rename SmalltalkImporter as SmalltalkExtractor like that we have a clear line.

- Nobody is referencing PackageDescription?

- Now our problem is that we would like to run tasks when a 

     a Smalltalk model is extracted and imported and when a mse file is imported.

     We should probably introduce the logic of the plugin login somewhere in a superclass and (MSEImporter should be a subclass of MooseTask - not verified if make sense)

- I have no clue about the contents of the Moose-GenericImporter. It looks like we stopped in the middle of something (which is probably true).

     - MooseImportingTask is still Smalltalk specific so I would move to the Moose-SmalltalkImporter.

     - MooseFileStructureImporter looks really broken but it can be a nice example of a subclass of MooseImporterTask (not MooseExtractorTask)

Doru it would be fun to do some pair programming to address these changes. Do you have time this evening?