runtime: Explicitly make process.* timing implementation-defined

Based on IRC discussion today (times in PST) [1]:

  11:36 < crosbymichael> just take a step back and think about it.
    you have a process object in the spec.  its a single object
    defining what to run.  How do you run a process?  you exec its
    args.  From the spec pov its an atomic operation.  in between
    create and start its not running the users code and is left up to
    the runtime.  you either have a process defined by the spec and
    its created as an operation in the container on start or your
    dont.

With the previous wording, it was unclear how large a hole we were
poking with "the user-specified program MUST NOT be run at this time".
This commit removes that ambiguous wording and replaces it with an
explicit reference to 'process.args'.  It makes it clear that
everything outside of 'process' MUST happen at create-time.  And it
leaves all of 'process' except for 'process.args' up to the
implementation.

This means that the caller has no reliable way to set the
user/cwd/capabilities/… of the runtime's container process between
'create' and 'start'.  You could avoid that limitation by requiring
all process properties *except* process.args be applied at
create-time, but my attempt to make process.args optional (which would
have allowed that interpretation without burdening callers who never
intended to call 'start') was rejected in favor of this all-or-nothing
approach to 'process' handling [2].

[1]: http://ircbot.wl.linuxfoundation.org/eavesdrop/%23opencontainers/%23opencontainers.2017-02-27.log.html#t2017-02-27T19:35:35
[2]: opencontainers#620 (comment)

Signed-off-by: W. Trevor King <wking@tremily.us>

Author: wking

runtime.md

@@ -100,9 +100,12 @@ This operation MUST return the state of a container as specified in the [State](
 
 This operation MUST [generate an error](#errors) if it is not provided a path to the bundle and the container ID to associate with the container.
 If the ID provided is not unique across all containers within the scope of the runtime, or is not valid in any other way, the implementation MUST [generate an error](#errors) and a new container MUST NOT be created.
-Using the data in [`config.json`](config.md), this operation MUST create a new container.
-This means that all of the resources associated with the container MUST be created, however, the user-specified program MUST NOT be run at this time.
-If the runtime cannot create the container as specified in [`config.json`](config.md), it MUST [generate an error](#errors) and a new container MUST NOT be created.
+This operation MUST create a new container.
+
+All of the properties configured in [`config.json`](config.md) except for [`process`](config.md#process) MUST be applied.
+[`process.args`](config.md#process) MUST NOT be applied until triggered by the [`start`](#start) operation.
+The remaining `process` properties MAY be applied by this operation.
+If the runtime cannot apply a property as specified in the [configuration](config.md), it MUST [generate an error](#errors) and a new container MUST NOT be created.
 
 The runtime MAY validate `config.json` against this spec, either generically or with respect to the local system capabilities, before creating the container ([step 2](#lifecycle)).
 Runtime callers who are interested in pre-create validation can run [bundle-validation tools](implementations.md#testing--tools) before invoking the create operation.