Initial implementation of agent generation.

This is hardcoded to expect some files in the lib directory in the working directory of the program, obviously a temporary solution for while i was working on it. @pdaian, can you please have the installer put these files together in a predictable location? (BaseAspect.aj  MANIFEST.MF  aspectjrt.jar  aspectjtools.jar  aspectjweaver.jar  rt.jar) from @owolabileg's [build-agent archive](http://fsl.cs.illinois.edu/images/6/6d/Build-agent.tar.gz).

This adds the --agent option, where the result of
`javamop --agent directory1 directory2 file1.mop file2.mop -n mopAgent`
reads all the files in directory1 and directory2 and uses file1.mop and file2.mop and produces a file `mopAgent.jar` that can be used as a java agent with existing java code.

This still needs some work (deleting intermediate generated files, and refactoring the code), but I'm putting this up now in case @owolabileg, @grosu, or @pdaian have comments.
For now, given the urgency of the task, it may be okay to hardcode the generation of the manifest file as in ```writeAgentManifest(File f)``` above. However, I don't think hardcoding the generation of the BaseAspect.aj file in the same way is a good idea. In my own work, I have had to add more to that file in different ways for different projects. For example, while monitoring projects that use junit, I would usually add something like ```!within(org.junit..*)``` to the BaseAspect.aj file, but that is not something that I want to do while monitoring junit itself. My point is: I think it is better not to generate this file from within JavaMOP this way as users may need to change it for monitoring their own projects, and we don't want them building from source weverytime they want to do that.