functional packages and iterated SFRs

There are cases where a PP-Module defines an iteration of an SFR originally from a Base PP that is now being moved to a Functional Package. Currently it is unclear how this should be handled (both from a CC standpoint and from the standpoint of representing it in the schema). For the sake of consistency we need to have a way to define this in a way that identifies the need for this SFR, the iteration that should be used for it, and any completed operations that need to be done to it for this specific iteration.

For example: the WLAN Client module defines FCS_TLSC_EXT.1/WLAN, FCS_TLSC_EXT.2/WLAN, FIA_X509_EXT.1/WLAN, and FIA_X509_EXT.2/WLAN. There is currently no place to say "include these particular SFRs at minimum from this functional package and give them this iteration name."

One possibility is that we have dummy headings for these components that allow you to specify where the SFR is actually defined with the ability to define an application note that gives further guidance. I'm not sure the extent to which this would be compatible with automation but at least from the perspective of generating an ST through automation, it would give the script a way to see what FP SFRs need to be included and what to call them.

So for example, maybe we could have a status="from-pkg" attribute on f-component which then tags the FP SFR that it's taken from with guidance on how to iterate it (iteration name implicit from the iteration attribute and an app note or some other tag to specify any operations that are needed). There would be no f-elements and it should not need any audit events or evaluation activities since those theoretically are inherited from the package.

so to the user it could look something like
FIA_X509_EXT.2/WLAN X.509 Certificate Support for Functions (EAP-TLS for WLAN)
The ST author iterates FIA_X509_EXT.2 from the Functional Package for X.509, version 1.0 and names it FIA_X509_EXT.2/WLAN.
The ST author selects [assignment: other authenticated communications protocol] and completes the assignment with "authentication for EAP-TLS exchanges".

That would address the current problem where we have no place for a PP or module to iterate SFRs from a functional package and tailor each iteration for the needs of each function that uses it. Obviously the NDcPP is not defined in here but the need to distinguish between FIA_X509_EXT.1/Rev and FIA_X509_EXT.1/ITT, both in terms of giving them consistent iteration names across different STs, and in terms of different requirements (FIA_X509_EXT.1/ITT permits shorter minimum path length because one TOE component can be the certificate issuer to another component whereas /Rev must always chain to an external CA through at least one intermediate) is another obvious situation where this sort of definitive instruction is needed.

Note that this is flagged as high priority due to its potential complexity and because it is directly applicable to a forthcoming wave of module updates.

No files or tests are named. Start at the schema's f-component representation and existing functional-package handling, then clarify how from-pkg references, iteration names, and completed operations should appear in generated ST output.