#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). 
> Besides, the current decorator implementation makes it even harder (see my PR #183 on decorators).

Agreed on that. The decorator stuff is rather experimental at this stage and definitely needs improvement.

> To be honest, I prefer the method with the @AfterMapping @BeforeMapping because of its simplicity on the cases were I require it.

I see. @agudian will like to hear that. Maybe there is something to this after all ;)

> What kind of java would you allow here? Constructors are not always a feasible approach (e.g. not for generated types). How about imports?

I haven't really thought about the details. It may be any Java code (including invocation of other mapping methods as an alternative to a constructor invocation). Imports might not really work (maybe one specifies them on the mapper type?). I also thought about using Unified EL which might simplify some things, but it comes at the price of another (optional) dependency and some performance overhead.