#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 would like deprecate / remove the existing (that you pointed out).

But why? The current approach is easy to understand and behaves as one intuitively would expect it. I really don't think we should deprecate this. The "sourcet and "target" attributes should always refer to exactly one property (be it in the source or target object itself or somewhere deeper in the tree using dot notation).

> Ok. But that does not fix the major part of this work: the reverse problem.

That's true. I feel the suggested approach isn't really intuitive to understand, though. I saw the `source = "time, format", target = "timeAndFormat"` syntax and immediately wondered how the two source attributes would be processed.

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. and you can do stuff such as trimming and so on. Remember, we don't need to support every edge case in (the code generated by) MapStruct itself if there is an easy way for the user to do certain things themselves.

> Furthermore, have that 'dot' notation already. Right? (ch 3.3 in the Mapstruct documentation). Only there the first part means the name of the argument iso a property

Yes, the parameter name can be specified as first element in a dot path when referencing an otherwise ambigious source property. It's similar to e.g. HQL/JP-QL where you can refer to properties either qualified or unqualified as required. Using dot paths to refer to nested properties fits nicely into this IMO.