restructure cmd output communication

Right now the frontend gets command output information by doing the following:
1. sending a request to the `/api/cargo` endpoint
1. requesting lines from both `/api/stdout_line` and `/api/stderr_line` until **both** give back and `"end"` response
1. requesting the command status from `/api/cmd_status`. this potentially happens in a busy loop until the command's status becomes available.

This is a lot of endpoints for a single command, so i think it would be nice to consolidate the three into one endpoint.

My new idea is:
1. send a request to the `/api/cargo` endpoint
1. repeatedly request data from a new endpoint named something like `/api/cmd_data`. this would send messages which are enum variants like
```rust
enum CmdMsg {
StdOutLine(String),
StdOutDone,
StdErrLine(String),
StdErrDone,
CmdStatus(i32)
}
```
1. once the frontend has received all three of `StdOutDone`, `StdErrDone`, and `CmdStatus`, the command is known to be finished.

This way the frontend can keep track of the command's state a little easier.

This would also allow for multiple simultaneous commands to be run because we could have the `/api/cmd_data` endpoint take a "process id" (or some internal ID) to identify which running process you are talking about.