#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). 
The concrete syntax depends on the specific expression language of course; Taking SpEL (which seems very attractive as it supports constructor invocations, unlike unified EL), the examples above would like this:

    @Mapping( target = "longWrapperConstant", expression = "3001")
    Target sourceToTarget(Source s); 

    @Mapping(
        target = "timeAndFormat",
        expression = "new TimeAndFormat( time, format )"
    )
    Target sourceToTarget(Source s); 

    @Mapping( target = "uom", expression = "'cm'")
    @Mapping( target = "value", expression = "value")
    PreDrilledDepth sourceToTarget(BigDecimal value);

If we want to be prepared for supportting several languages (which I think would be a good idea), then we could do the following:

    @Mapping( target = "uom1", expression = "spel('cm')")
    @Mapping( target = "uom2", expression = "java(\"cm\")")
    PreDrilledDepth sourceToTarget(BigDecimal value);

Depending on the chosen language, a different "translator" would be invoked.