#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). 
> 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?

Hey Sjaak, yes, if we go for plain Java code to be given via `expression()` (which I think is what we should start with), then Strings would indeed have to be given in escaped quotes. I guess you could do it as part of this PR?

> Or do you want to abandon the current implementation al-together?

I think that's what it basically means. We'd remove the application of built-in conversions and just pass through the given expression as source reference. I kind of liked the conversion routine, but being able to specify "full" Java seems more versatile and powerful, e.g. your use case where several source attributes contribute to one target property, should be nicely be addressed by this.

Maybe you would like to play around a bit with this and see whether it proves useful?

Note that I'm not sure whether some simplied scripting expression facility might not be the better alternative, but I guess we just should move forward with something and can re-consider things later on.