config: Link platform:"..." JSON tags with platform slugs

So that the semantics of the tags are clear.

The platform/protocol disconnect is unfortunate.  "Protocol" was
chosen in de3f1af (Remove language around Solaris being optional as
it is covered in compliance language, 2016-08-17, #527) because we may
have compliance subsets that aren't linked to platforms [1].  I'd be
open to renaming the JSON tag from platform:"..." -> protocol:"...",
but that's probably more change than it's worth.  The approach taken
in this commit, on the other hand, renames "protocol" to "platform".
I think that unnecessarily limits (or sets up confusing semantics for)
the platform/protocol values you can use, but two maintainers both
prefer "platform" [2,3].

[1]: #527 (comment)
[2]: #570 (comment)
[3]: #570 (comment)

Signed-off-by: W. Trevor King <[email protected]>

Author: wking

config.md

@@ -2,7 +2,8 @@
 
 The container's top-level directory MUST contain a configuration file called `config.json`.
 The canonical schema is defined in this document, but there is a JSON Schema in [`schema/config-schema.json`](schema/config-schema.json) and Go bindings in [`specs-go/config.go`](specs-go/config.go).
-Platform-specific configuration schema are defined in the [platform-specific documents](#platform-specific-configuration) linked below.
+[Platform](spec.md#platforms)-specific configuration schema are defined in the [platform-specific documents](#platform-specific-configuration) linked below.
+For properties that are only defined for some [platforms](spec.md#platforms), the Go property has a `platform` tag listing those protocols (e.g. `platform:"linux,solaris"`).
 
 The configuration file contains metadata necessary to implement standard operations against the container.
 This includes the process to run, environment variables to inject, sandboxing features to use, etc.

spec.md

@@ -2,7 +2,9 @@
 
 The [Open Container Initiative](http://www.opencontainers.org/) develops specifications for standards on Operating System process and application containers.
 
-Protocols defined by this specification are:
+# Platforms
+
+Platforms defined by this specification are:
 
 * `linux`: [runtime.md](runtime.md), [config.md](config.md), [config-linux.md](config-linux.md), and [runtime-linux.md](runtime-linux.md).
 * `solaris`: [runtime.md](runtime.md), [config.md](config.md), and [config-solaris.md](config-solaris.md).
@@ -28,8 +30,8 @@ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "S
 
 The key words "unspecified", "undefined", and "implementation-defined" are to be interpreted as described in the [rationale for the C99 standard][c99-unspecified].
 
-An implementation is not compliant for a given CPU architecture if it fails to satisfy one or more of the MUST, REQUIRED, or SHALL requirements for the protocols it implements.
-An implementation is compliant for a given CPU architecture if it satisfies all the MUST, REQUIRED, and SHALL requirements for the protocols it implements.
+An implementation is not compliant for a given CPU architecture if it fails to satisfy one or more of the MUST, REQUIRED, or SHALL requirements for the [platforms](#platforms) it implements.
+An implementation is compliant for a given CPU architecture if it satisfies all the MUST, REQUIRED, and SHALL requirements for the [platforms](#platforms) it implements.
 
 [c99-unspecified]: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf#page=18
 [rfc2119]: http://tools.ietf.org/html/rfc2119