config: Clarify capabilities(7) as the canonical source of Linux caps

[wking]

With the “valid values it chooses to not support” language from #673, the runtime is clearly free to support a subset of the platform's capabilities. But the runtime should not be free to change the semantics of valid values (e.g. CAP_CHOWN should always mean the same thing on Linux, regardless of which runtime you use).

[wking]

Hmm, this is still not quite right. We may need to strengthen “semantics” and bind each property directly to something that can be directly tested for compliance. For example, by saying that values set in process.capabilities MUST be included in the result of a successful capget(2) call on the container process. There has been resistance to tying the spec implementation too tightly to the underlying kernel, but I don't see another way to justify compliance tests based on retrieving the process capabilities.

[crosbymichael]

@wking You need to separate valid values and compliance from errors. Caps change and you have to defer to the underlying platform for validation. You cannot base compliance on the host system that you are running compliance tests on. The current wording in master is correct for what should happen.