#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). 
> On the topic, my feeling is that we shouldn't allow stuff that we can't check at generation-time and that we can't transform to plain java code. So what ever we do with such expressions should be parsed, checked and transformed to simple java code.

Hmm. What's the problem with "compile" time checking of included java code? There used to be a time (not so long ago :) ) that we did not have IDE's that do continues build and you actually did have to push the compile button to get a result.

My thinking was, rewriting the current constant mapping (expression) a little bit, so that you have to include a `String`, like this: 

```java
    @Mapping( target = "longWrapperConstant", expression = "\"3001\""),
    Target sourceToTarget(Source s); 
```
and then, in a next step allow expressions like @gunnarmorling  proposes:
```java
    @Mapping( target = "longWrapperConstant", expression = "new TimeAndFormat(time, format)"),
    Target sourceToTarget(Source s); 
```
however, we might borrow some 'notational' stuff from Freemarker like this:
```java
    @Mapping( target = "timeAndFormat", expression = "new TimeAndFormat(${s.time}, ${s.format})"),
    Target sourceToTarget(Source s); 
```
which by the way, solves another case for me as well PR #182, like this:
```java
    @Mappings( {
        @Mapping( target = "uom", expression = "\"cm\""),
        @Mapping( target = "value", expression = "${value}"),
    } )
    PreDrilledDepth sourceToTarget(BigDecimal value); 
```
Brilliant I would say :).

My first attempt would indeed rely on the compilation step to get it correct. Otherwise we have to limit the type of expressions to:
1. String Constants (as now, and let conversion solve the mapping)
2. Constructors
3. Factorries