Follow up of #60:

• create a dotted path notation for error messages where nested properties can't be mapped automatically
• Adapt reference documentation
• Add entry to migration notes to note that there won't be an error message in case nested properties can be mapped automatically
• Make sure that configuration from prototype methods in @MapperConfig classes are applied to forged methods (I think that's currently not the case and never has been -- but we should tackle that soon as it becomes more important now). This is now Use configuration from prototype methods for forged name based methods #1086
• Align ForgedMethods with current ForgeMethod approach. ForgedMethods should not be properties on BeanMapping and PropertyMapping. The name should be generated based on the uniqueness of the method. See also discussions in Unexpected code generated for update method icw nested target properties #1011. A testcase should be added to verify this truly works (e.g. forcing the same name, with different property mappings). This could be done for instance by taking a DTO with the same name from different packages.
• TestMultipleForgedMethodsTest needs to do some assertions: create proper input data and assert the results. Rename the test class itself (Test*Test) and rename the classes Bar, BarDto, Dto... :)
• Should work for update methods too