Ensure that StartAndAttach locks while sending signals

The OCI Runtime's KillContainer interface can modify container
state (if the signal fails to send, as it would if the container
failed immediately after starting, we will update state to pick
up the fact that the container exited). As such, it can edit the
DB, and needs to be run locked.

There are fortunately only a few places where this function is
used, and most of them are already safe. The only exception is
StartAndAttach(), which does a SIGWINCH in an unlocked portion of
the function. Fortunately it's a goroutine, so just add a lock
and defer unlock and it should be fixed.

[NO NEW TESTS NEEDED] I have no idea how to induce a scenario
that would cause this consistently.

Signed-off-by: Matthew Heon <matthew.heon@pm.me>

libpod/container_api.go

@@ -282,6 +282,8 @@ func (c *Container) Attach(streams *define.AttachStreams, keys string, resize <-
 	if c.Terminal() {
 		go func() {
 			<-attachRdy
+			c.lock.Lock()
+			defer c.lock.Unlock()
 			if err := c.ociRuntime.KillContainer(c, uint(signal.SIGWINCH), false); err != nil {
 				logrus.Warnf("Unable to send SIGWINCH to container %s after attach: %v", c.ID(), err)
 			}