Modularize parser component

This build made some refactoring on the structure of the project so that Parser Component has a clearer API now. The other components can communicate with Parser Component by the ParserService Interface. The clients of Parser Component do not need to bother how to manipulate different parts of the parser to finish a task now, what the other components need to do is providing the input to appropriate port of the ParserService instance, and then the desired output will be returned. The clients who use Parser Service can put new requirements on Parser Component by adding methods in ParserService Interface. 
@owolabileg  @pdaian  @yzhang90 Please review.
 
As far as I understand, the parser component should be responsible for these two methods: both the input and output reside inside the parser package. MOPSpecFileExt is inside "parser/astex" while MOPSpecFile is inside "parser/ast". At the current stage, almost every class is visible to every class else inside the project!! Each time when a developer needs to get some intermediate result, instead of thinking how to find the right module and delegate the task to that specific module, he might implement that function outside of the right component. This will definitely increase the risks of having duplicate code and make the code hard to maintain (Functions serve for similar purposes all around the project and therefore hard to make them consistent if changes are needed). In this refactor, I also encapsulate most of classes inside parser component so that they are not directly visible to outside world. I think it will benefit in the long term if the parser-related stuff can be used in a more controllable way.