rethinking the structure of modules and exports

currently, after being built, Products effectively lose all file information: the modules they export contain only Depends and a bunch of properties which are directly consumed by specific Rules (e.g., include paths and linker flags).

this severely limits the possibilities, as the modules' contents are effectively opaque, and their contained information is tailored to specific use cases.

instead, the exported modules should contain groups of tagged files, just as the Product specifications which lead to their creation do. specifically, the file lists would be the output of the Product's installs.

an implication of this is that tags are determined at module creation time. this includes specific tags like "static_library" and "cxx_header" and category tags like "runtime" and "development". custom tags would be specified in the install rules.

this would allow the consuming Rules/Transformers to work with much more "raw" data, which leaves a lot of room for specific processing.

additionally, it would unify the structure of modules from all sources to be centered around files as much as possible:

• in a source module (typically, a Product's source), the file list is verbatim what the user specified, plus the filetagger run
• for exported modules, it's the install output
• in the case of externally obtained modules, it's whatever the factory (configure stuff) which created the module thought appropriate

exported modules could still contain properties, for example to force specific defines upon users. but the central idea is to minimize the fixed-purpose data.