Refactor Module SourceSerialization to allow generating (new) binary resource names in process

HCM-50 introduced generating resource names for new binary values, to be able to (only) allow them to be serialized separately from the yaml sources.

However the current processing flow within SourceSerializer complicates this as it tries to do this as a post (yaml) representation task, thereby requiring collecting such PostProcessItem objects during the representation phase.

The Source serialization instead can be refactored into a 2-phase proces which will make this a more clean separation of concern, as well as enable implementing the 2nd phase as a streaming process (separate issue: HCM-72).

In the 1st phase all predefined resource paths from all Sources of a Module should be collected.

In the 2nd phase these resource paths then can be used for representing+serializing each Module Source, including generating new binary property value resource names and their output files on the fly.

For that purpose the predefined resource paths need to be available which can be done through a (new) ModuleContext.  The ModuleContext then also can take care of generating the resource file names and creating the outputstreams to write to.

Specific attention is needed for detecting name clashes between aleady known resource paths, which need to take the full filename (including extension) into account.
Furthermore, a filename also must not clash with a path (directory) element of a known resource path.

Finally the ResourceNameResolver interface needs to cater for extensions / plugins which can generate more efficient/user-friendly resource names based on the context of the value (e.g. its property and parent hierarchy). 

HCM-90 will provide example smart ResourceNameResolvers, like for hippogallery:thumbnail etc.