validation: fix two lifecycle assertions that contradict the spec

[dangowrt]

Two validation tests assert the opposite of what the runtime-spec requires, and between them they make one requirement untestable and another impossible to satisfy.

validation/start asserts that start returns no error for a container created without a process, while reporting the result under StartWithProcUnsetGenError, which specerror registers as a MUST against runtime.md#start: "This operation MUST generate an error if process was not set". Combined with the command line interface requirement that start exits "non-zero on errors", a compliant runtime must fail here, and the test marks it as broken for doing so while passing a runtime that silently returns success. The assertion is inverted to expect the error.

Please note what that means in practice, because it is not comfortable: crun 1.29.1 fails the corrected assertion. crun start on a container with no process prints "block process not found" and then exits 0, so on current master start.t reports 7 ok and with this change it reports 6 ok and 1 not ok. I believe that is the test finding a real defect rather than a regression, given the two sentences quoted above, but it is the maintainers' call and I would rather raise it here than have it turn up after a merge.

validation/pidfile fails against any runtime that gets kill right. Its teardown waits for the container to be running, which never happens because the container process is true and has already exited, discards the resulting timeout, kills the stopped container anyway and then returns that kill error as the outcome of the --pid-file check. runtime.md#kill says signalling a container that is neither created nor running MUST generate an error, and validation/kill case four asserts precisely that and passes, so the two tests cannot both be satisfied. kill.t is the one with the spec behind it and is left alone; the pid file teardown now waits for the process to exit on its own, which is all it ever needed.

Fixes #805

One loose end that belongs in runtime-spec rather than here. With the start assertion corrected, the container is left in whichever state the runtime chose, and the spec has no defined route out: a failed operation "MUST leave the state of the environment as if the operation were never attempted" so it stays created, delete MUST reject a container that is not stopped, and kill is defined in terms of a container process that a process-less container does not have. The test therefore tears down on a best-effort basis and asserts nothing about how. I intend to raise that gap against runtime-spec separately.