Support ModuleOptions for composed modules

With the following semantics (assuming http | filter | transform composition):

• Fully qualified names always available (eg filter.expression)
• using module type as key
• or label if ambiguity
• Simple names available if no ambiguity (eg here "port" refers to http.port)

As per discussion:

VIII) Use of “--expression” option in composed module “filter | filter”
Should not be supported (require FQN always)
Should pertain to first filter module (always)
Should pertain to all modules with an “expression” option (here: both filters)
Should fail if not qualified and ambiguity. Use label.expression (or type.expression, eg if we had “filter | transform) (see VII ⇒ nesting1.nesting2.nesting3.expression) (MF)

VIII) Use of “--expression” option in composed module “http | filter --expression=something | transform”
Should not be supported (already valued)
Should pertain to first filter module (always)
Should pertain to all modules with an “expression” option (here: both filters)
Should fail if not qualified and ambiguity. Use label.expression (or type.expression, eg if we had “filter | transform) (see VII ⇒ nesting1.nesting2.nesting3.expression) (MF)