#113 renaming unit test, adding unit test, implementing solution

For quick understanding :) please look at tests:
1. `org.mapstruct.ap.test.multiple.manytoone.SourceTargetMapper`
2. `org.mapstruct.ap.test.multiple.onetomany.SourceTargetMapper`

This is a first attempt. This solves a considerable part of the current issues I have. 

About the solution, I need to add unit test for the error situations that are introduced. But have a look and see if this makes sense. If I need other tests as well ,let me know.

I'm thinking of deprecating (or removing, suggestions?) the current multiple sources mechanism (so, where a `@mapping` to the same target is allowed more than one time in the `@Mappings`) in favor for the newly introduced comma separated mechanism (in order to align with many-sources-to-one-target). 
I've thought a bit more about the issue of expressions. I can see at least the following possibilities:

1. Embed plain Java code as discussed above
1. Embed expression language code (Unified EL, SpEL etc.) and transform it into equivalent Java code at build time by MapStruct
1. Embed expression language code and let MapStruct generate code which interprets that code at runtime of the generated mapper

All options have their different pro's and con's of course. 1. would be implemented rather easily, at the price of a more verbose syntax. 3. gives a more compact syntax but we loose the advantage of build-time safety and the generated code contains a dependency to the EL runtime.

Option 2. seems all in all the best to me from a user perspective, as it gives a concise syntax, there is no runtime dependency (as we would generate plain Java code) and it's type-safe. But it is the most complex solution implementation-wise, as we'd need to create a transformation for each construct of the chosen EL language. E.g. JUEL or SpEL provide access to their ASTs which one then can traverse and create a corresponding Java statement while doing so. It's not particularly difficult, but I guess it will be quite a lot of effort if we want to do it completely.

I still think that'd be my preferred approach as it's the best for the user and offers great possibilities. E.g. being able to use the [collection projection](http://docs.spring.io/spring/docs/4.0.x/spring-framework-reference/htmlsingle/#expressions-collection-projection) ability from SpEL would be fantastic.

Note that one could also compine 1. and 3. by supporting several languages in the `expression` attribute and offering a configuration option which language is used. @sjaakd, @agudian, what do you guys think?