If workspace is locked, message should say due to cmd running for which commit sha

[jolexa]

Hello,
This is an interesting user experience. In this case, the plan had an error and exit 1, at that point the tf code was fixed and then the next atlantis plan (autoplan) started running. Since the EC2 API has been degraded most of the day, a plan was running for a very long time. Then, we tried to manually run plan and got the workspace is locked message even though we have no way to fix it.

So, a few things here to think about:

1. Atlantis can send messages out of order. It might be nice to say, "another plan is running for commit $hash"
2. Maybe a timeout option is needed?

[majormoses]

Ya that makes sense to have some kind of "pointer", normally I think a git sha would be a good idea but I think that could be misleading with #427 which will rebase in additional changes but not commit them back to the remote. While the the "pointer" would still be right from a user traceability stance it is misleading because it's actually executing against different code from what you have in that branch. I suppose that could be OK as long as it's documented or stated in the comment itself about that behavior.

Maybe a timeout option is needed?

I think that needs to be a different discussion on wanting to implement timeouts, it would affect a lot of workflows for example that have RDS creations which can last 40 minutes or longer.

One thought I had was once we implement #305 which would solve the problem I think and is something that most CI providers support. Applies would be a bit different because aborting an apply is not currently safe per #187