#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 think this particular problem is better handled using a decorator and setting the target value from hand. Handling several source attributes to create one target property is IMO better handled using "real" Java code where you get auto-completion etc

Hmm. I don't really agree. In my particular scenario I've got a still growing number of common asymmetric mappers (so mappings with one target and several sources, including the reverse mappings). If I need to handle this via the decorator (so java coding) it will be on a lot of places which compromises the use case for Mapstruct. 

Besides, the current decorator implementation makes it even harder (see my PR #183 on decorators). To be honest, I prefer the method with the `@AfterMapping` `@BeforeMapping` because of its simplicity on the cases were I require it.



> That being said, I think there may be a viable solution via the "expression" attribute, e.g. like so:
> 
> @Mapping(target="timeAndFormat", expression="new TimeAndFormat(time, format)")
> In other words, source should be used for plain mappings (including references to nested properties to cater for the common case of "flattening" a source hierarchy), whereas I envision expression to be useful in more complex cases such as the one at hand. For this we'd have to agree on a syntax to be used in expression, so far I considered plain Java code, only properties would have to be resolved and modified into "proper" getter references.

Now.. That Idea I like :) :+1: I need some time to digest that one.. Lets explore that idea further.. What kind of java would you allow here? Constructors are not always a feasible approach (e.g. not for generated types). How about imports?