#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). 
> We allow for plain Java code to be given via `expression()`. This would be used as the "source reference" in the generated code and would allow for quite some powerful things such as constructor invocation, simple calculations etc. Plus, we'd get the compile-time checking basically or free: Either the generated code - which would contain that snippet as is - either compiles or not. On the down-side, one would have to manually care for type conversions; Also imports may be an issue. Properties would have to be referenced via their getter.

What about the current implementation? Would the user have to double-quote the current `String` like `"\"0.5\""` in order to continue using this? Should I write a small PR to fix this? Or do you want to abandon the current implementation al-together?