#65 support for nested properties

Finally, after a lot of iterating hence-and-forth. Here's the solution for nested properties as discussed in #65.

Some points addressed:

1) (Error)Checking of the source side has been moved to (construction-time) of the `@Mapper`
2) `BeanMappingMethod` has been restructured. It first creates a  'todo' list of target properties, and than slowly empties the list by first handing the defined `@Mappings` that act on a target property, and then handles the remaining properties based on name.
3) Finding a suitable name candidate is handled completely in `BeanMappingMethod`
4) `SourceReference` contains all required information on the source part of the mapping distilled from the source information (so method and mapping). 
5) `BeanMappingMethod#build` became to large. It has been partially refactored, although perhaps not as much as I desired. An `getPropertyMapping` should perhaps be made per `TargetAccessorType` iso squeezing them all in the same method. But that's for a next refactoring :).
6) I used the existing `ForgedMethod` mechanism to handle the nested properties in an isolated fashion. That leaves room for extension (e.g. list and map support).
7) I handled the parameter-only (so no source bean) case as well.

Two questions, out of curiosity:

1. Is the local variable created using that unique-name algorithm that we already have in place? E.g. if you meet euqally named properties more than once on a property path (we have property paths such as "foobar.country.country.code", where both country properties resolve to different types, though.

2. There is some opinion out there that says it's bad style if a method has more than one "return" statements, but here that could lead to deeply nested if-clauses (which then don't look that nice anymore in the generated code). Did you guys consider using the following pattern instead?
```
if ( ... == null ) {
   return null;
}
// check next level
 ..
```