Matching composition & runtime flows/flow-details

Currently we have an API that allows for *named* flow patterns to be nested inside other flow *named* patterns. When that accumulated unit is ran it then gets flattened into a single structure and then ran with a *single* flow-detail (and composed other atom-details) instead of running with N flow-details (one for each *named* nesting level). This single flow-detail corresponds to the the top most named flow (aka the root), thus meaning we discard the contained other N-1 flow details that could be used as well.

One option/idea to make this less confusing would be that we would enforce and validate that all nested flow patterns were instead of a anonymous pattern type (aka, no name is possible) so that this is clear to the user of taskflow when constructing and running that there will be only a *single* flow-detail that will actually be used during running (the root must be named).

Another option is to fix the current API and create N flow-details (and at runtime use the atoms *parent* associated flow-detail when saving and reading state/results...), this option IMHO better matches the structure that was created at pattern and atom composition time but it does introduce more complexity around reading, writing and associated atomicity of those operations...