runtime: Remove "features the runtime chooses to support"

Step 3 of the lifecycle from before this commit had two sentences
which both landed in be59415 (Split create and start, 2016-04-01,
opencontainers#384).  I pushed back a bit on the entry then [1,2], but we seem to be
pretty comfortable with the current "keep all lifecyle entries in a
one-layer enumerated list" approach, so I'm leaving that alone in this
commit.  Step 3 isn't really a lifecycle step though, it's more about
clarifying that you can jump around in the lifecycle instead of
hitting all the steps in consecutive order.  I'd floated a new
paragraph addressing that jumping, but was unable to form a consensus
around wording, and the jumping is already somewhat covered by the
current list entries (e.g. "The container process exits.").  This
commit just drops the old step 3, and Michael will follow up with
wording about jumping [3].

The other sentence from the old step 3 doesn't need replacing, because
the limits are already covered in more detail in the operation
sections themselves.  For example, the 'delete' operation has:

  Attempting to delete a container that does not exist MUST generate
  an error.  Attempting to delete a container whose process is still
  running MUST generate an error.

I don't see the need to call generic attention to that idea, and
especially do not think that an entry in the lifecycle list is the
right place for such a generic call-out.

[1]: opencontainers#384 (comment)
[2]: opencontainers#384 (comment)
[3]: http://ircbot.wl.linuxfoundation.org/meetings/opencontainers/2017/opencontainers.2017-05-10-21.03.log.html#l-79

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

Author: wking

runtime.md

@@ -18,8 +18,8 @@ The value MAY be one of:
 
     * `creating`: the container is being created (step 2 in the [lifecycle](#lifecycle))
     * `created`: the runtime has finished the [create operation](#create) (after step 2 in the [lifecycle](#lifecycle)), and the container process has neither exited nor executed the user-specified program
-    * `running`: the container process has executed the user-specified program but has not exited (after step 4 in the [lifecycle](#lifecycle))
-    * `stopped`: the container process has exited (step 5 in the [lifecycle](#lifecycle))
+    * `running`: the container process has executed the user-specified program but has not exited (after step 5 in the [lifecycle](#lifecycle))
+    * `stopped`: the container process has exited (step 7 in the [lifecycle](#lifecycle))
 
     Additional values MAY be defined by the runtime, however, they MUST be used to represent new runtime states not defined above.
 * **`pid`** (int, REQUIRED when `status` is `created` or `running`) is the ID of the container process, as seen by the host.
@@ -55,19 +55,17 @@ The lifecycle describes the timeline of events that happen from when a container
    If the runtime is unable to create the environment specified in the [`config.json`](config.md), it MUST [generate an error](#errors).
    While the resources requested in the [`config.json`](config.md) MUST be created, the user-specified program (from [`process`](config.md#process)) MUST NOT be run at this time.
    Any updates to [`config.json`](config.md) after this step MUST NOT affect the container.
-3. Once the container is created additional actions MAY be performed based on the features the runtime chooses to support.
-   However, some actions might only be available based on the current state of the container (e.g. only available while it is started).
-4. Runtime's [`start`](runtime.md#start) command is invoked with the unique identifier of the container.
-5. The [prestart hooks](config.md#prestart) MUST be invoked by the runtime.
-   If any prestart hook fails, the runtime MUST [generate an error](#errors), stop the container, and continue the lifecycle at step 10.
-6. The runtime MUST run the user-specified program, as specified by [`process`](config.md#process).
-7. The [poststart hooks](config.md#poststart) MUST be invoked by the runtime.
+3. Runtime's [`start`](runtime.md#start) command is invoked with the unique identifier of the container.
+4. The [prestart hooks](config.md#prestart) MUST be invoked by the runtime.
+   If any prestart hook fails, the runtime MUST [generate an error](#errors), stop the container, and continue the lifecycle at step 9.
+5. The runtime MUST run the user-specified program, as specified by [`process`](config.md#process).
+6. The [poststart hooks](config.md#poststart) MUST be invoked by the runtime.
    If any poststart hook fails, the runtime MUST [log a warning](#warnings), but the remaining hooks and lifecycle continue as if the hook had succeeded.
-8. The container process exits.
+7. The container process exits.
    This MAY happen due to erroring out, exiting, crashing or the runtime's [`kill`](runtime.md#kill) operation being invoked.
-9. Runtime's [`delete`](runtime.md#delete) command is invoked with the unique identifier of the container.
-10. The container MUST be destroyed by undoing the steps performed during create phase (step 2).
-11. The [poststop hooks](config.md#poststop) MUST be invoked by the runtime.
+8. Runtime's [`delete`](runtime.md#delete) command is invoked with the unique identifier of the container.
+9. The container MUST be destroyed by undoing the steps performed during create phase (step 2).
+10. The [poststop hooks](config.md#poststop) MUST be invoked by the runtime.
     If any poststop hook fails, the runtime MUST [log a warning](#warnings), but the remaining hooks and lifecycle continue as if the hook had succeeded.
 
 ## <a name="runtimeErrors" />Errors