- added fillDescriptions
- fixed a bug when filter not supposed to produce a data product
- allow testing for missing data products

Use proper module label and avoid reusing a module.

- avoid unnecessary check on alias finding
- break out of loop properly

The bit position of a module onto a path does not have to be the same as the modules order to be run on the path.
This is needed to allow ConditionalTasks to be added to a path in a set run order but still be able to use the unaltered parameter value holding the list of module labels in order to later find the module labels.
All ConditionalTask's modules are added to the end of the parameter and are bracketed by two non-module labels [# and @]. Modules added explicitly to the path are at the front of the parameter and in their run order.
The TriggerNamesService knows how to translate the path bit position into the proper module label stored in the parameter.

This allows sharing of this code across two cases.