#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.

> Isn't there an issue on messages in general that we could use to do this?

Not sure out of my head :) The double mentioning of the property type was what caught my attention here.

> Long messages make it harder to pick out the real problem. WDYT?

Agreed, I think we generally should prefer simple names over qualified ones. The error marker is added at the right location, so it should be clear from that context to which type such simple name refers.