CPS should have component visibility

[mwoehlke]

For various technical reasons, some packages are very likely to consist of several libraries of which some are not intended to be directly consumed by external users. Because CPS strongly recommends that each library has a corresponding component, this means that "properly written" CPS files may need to reference components that should not be externally referenced.

This is a classic incarnation of the common "visibility problem". While recognizing that circumvention will be possible — and, also, that this is not a critical issue — it would be clearly beneficial to have a way to mark a component as "local" to a package.

We should add such an attribute. A component so-marked may be required by another component of the same package, but directly referencing it from another package / the consuming build should be strongly discouraged. (Read: tools shall be permitted to treat this as an error.)

See #29.

[bretbrownjr]

Yep. My interpretation of previous discussion about this feature is that there's already demand to model this.

I can imagine we'll also want to support an allowlist of other packages that can reference hidden/private components to assist in software engineering exercises like merging or splitting projects, but we let's start with this and circle back to more (in)visibility features in the future.

[bretbrownjr]

We discussed this again in the C++ Ecosystem Evolution meeting today. We have consensus on the following:

• Add documentation to cps-wiki about how to provide internal components -- components that are modeled by build systems but should not be named by external consumers.
• The expectation is that tools would provide an error diagnostic for use of internal components, though ability to override the diagnostic seems important as a practical matter
• Demonstrate how a multi-library *.pc file maps to use of one or more internal components