Add convenience methods to create ArtifactContainerDescriptor for default cases

[nils-christian]

Similar to #5, I found some presumable default cases for ArtifactContainerDescriptors. I tend to categorize my building blocks usually by the package name. Therefore one could imagine methods to create descriptors based on a partial match of the full qualified name or based on a regexp maching the full qualified name of the java class in question:

ContainerDescriptorHelper.forFQNContaining( ArtifactContainerType.of( "Module" ), ".read.", "Read Models" ) 

or

ContainerDescriptorHelper.forFQNMatching( ArtifactContainerType.of( "Layer" ), ".*\.frontend\..*", "Frontend" ) 

[nils-christian]

I opened a PR for this issue.

[OLibutzki]

That's interesting as I have described my containers differently, see ModuleDescriptor.

I had business containers in mind, but you built technical containers. I am not sure if this is the same idea. As each artifact can only have one container it seems not to scale. Don't you run into issues using this appoach?

[nils-christian]

Well, my example application is rather small (it is a housekeeping book) and has thus only a single "business case". So in this case I prefer the separation into technical containers. Also I always expect that one would build different Archifact applications based on the same classes to describe different point of views. Thus I don't really see a contradiction.

[nils-christian]

Apart from the already mentioned descriptors relying on the FQNs, we are also using annotations on package level. This might also be a common use case. I am still wondering which of these descriptors are the most common use cases and should thus be part of the API. The definition for the building blocks was much easier.