Some clarification regarding secondary command buffer lifecycle

In section 6.1, a list of possible states for command buffers is given. On one side, the spec says
> Executable command buffers __can__ be submitted, reset, or recorded to another command buffer.

and on the other

> if the primary is submitted to a queue, both the primary and any secondaries recorded to it move to the _pending state_

This seems slightly contradictory in the case of a secondary that does not have `VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT` set, which is then recorded to a primary but not yet submitted: the secondary is not pending until it has been submitted, but it also cannot be submitted or recorded to another command buffer. So what state is it _actually_ in at this stage?

Related to this is the case touched upon briefly in #414: a secondary that's recorded to a primary which is then reset without being submitted. If the secondary has `VK_COMMAND_BUFFER_USAGE_ONE_TIME_SUBMIT_BIT`, what state it in when it is recorded to a primary, and the primary is then reset? Does the secondary become executable again, or invalid?

Review section 6.1 of the Vulkan specification and the related discussion in #414, focusing on secondary command buffers recorded to an unsubmitted primary and the ONE_TIME_SUBMIT_BIT case. Clarify the resulting command-buffer states and update the specification wording so these lifecycle transitions are unambiguous.

Written by the indexing model from the issue text.