#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). 
> It sure looks nice, but I would rather try to implement and hook-in some code of my own than to fiddle around with that many annotations.

But you loose oversight, having to go to a decorator or `@BeforeMapping` / `@AfterMapping` to figure out what's going on. Especially when you have many of them. Next to this, you specify the normal / reverse methods on different places. Finally, I believe its the idea to take (boring, error-prone) mapping work away from the developer. In that sense, each line of code towards that goal helps (especially when there are lot of those individual lines :) ).

> So better start with a smaller, but safer set of expressions, and extend that as we go further. But I guess that's something for a discussion in its own issue, right?

Right. Perhaps its time to lay down some MapStruct principles that should be obeyed, to drive a common understanding and direct the solution a bit. This could be one. The 'source should be used for plain mappings' that @gunnarmorling mentioned above is another.