Adjust product specification to allow creator names

[knoepfel]

The goal is to permit registration code like:

g.transform("A", make_an_a).input_family(...);
g.transform("B", make_a_b).input_family("A"_in("spill"));

where the output name of the product created by transform "A" does not need to be explicitly specified for transform "B". This means that the specified name corresponds to the node name and not the name of the data product. The name of the data product only needs to be specified to disambiguate between other products produced by the same creator with the same type.

[marcpaterno]

The diagram below shows the workflow I believe is intended in the test test/anonymous_products.cpp.
The notation on the arrows between nodes shows the type and what I think (but am not sure) we have decided to call the suffix of the product communicated along the arrow. Note that some suffixes are the empty string, denoted by ''.

The text inside a box is the name of the node. For transforms, this name becomes the creator_name associated with all the products the transform produces. For the prototype, I think this should hold for providers as well.

graph TB
    PN([provide_numbers])
    PO([provide_offset])
    SqN(square_numbers)
    SN(sum_numbers)
    SSN(sqrt_sum_numbers)
    PN -->|"numbers_t, numbers"|SqN
    SqN -->|"numbers_t, ''"| SN
     SN -->|"unsigned,''"|SSN
     PO -->|"unsigned,offset"|SSN

Loading

I think the registration statement for the transform node named "square_numbers" needs some modification, such as:

 g.transform("square_numbers", square_numbers, concurrency::unlimited)
    .input_family(from("provide_numbers").in("job")) // THIS IS STILL INCOMPLETE
    .output_products("");

The "THIS IS STILL INCOMPLETE" marker is there because we need a way to specify that this node is looking for the suffix "numbers". (I note that in this case, we could have the provider not use a suffix, and then in this case nothing more is needed. But for the general case, a provider may return a product with a non-empty suffix, so we need a way to specify that in the product lookup).

Then many (perhaps almost all) of the existing workflows need to be modified so that the downstream node are using the input_family(from(...)) syntax to find the products returned by the provides.

[beojan]

For prototype 0.1, I was envisaging using the old "suffix"_in("layer") notation to find a product by suffix, and from("creator").in("layer") to find a product by creator name. I don't like the inconsistency but that avoids having to modify existing workflows.

If we delay this to prototype 0.2 we should deal with the API break and design a single consistent syntax. I would make product_tag a struct holding the various fields constructed using the designated initializer syntax, and have product_query constructed from a product_tag (mostly only so the type can be automatically filled in). Something like:

g.transform(...)
  .input_family(product_query({.creator = "provide_numbers",
                               .suffix = "number",
                               .layer = "job"})
  .output_products("");

[marcpaterno]

This sounds like a good direction for prototype 0.2. Let's wait until 0.1 is out, and then consider if any fine-tuning is needed,