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

Yes, that does not sound like it is as it should be. @sjaakd, could you open an issue and describe what you see leaked? You can assign it directly to me. I should have some time again for MapStruct soon.
Btw: specifying different sets of classes to different test methods also comes with quite a performance-penalty. If it's all the same for the test case at hand, it would be better, IMO, to specify all the required classes for the whole test class. The I/O for deleting, compiling, class-loading all the stuff each time is very noticable, at least for me on Windows.