As a developer, I don't want to have to duplicate code between the UI and CLI, so I want the backend to provide derived values in the API. One such derivation is from the combination of a WorkspaceBuild's transition (to be renamed "action") and its job's status into the current status of the workspace.

Here is the desired mapping from job status to workspace status:

pending: [transition]ing (starting, stopping, or deleting)
running: [transition]ing (starting, stopping, or deleting)
succeeded: [transition]ed (started, stopped, deleted)
failed: failed
canceling: canceling
canceled: canceled

This workspace status should be provided in a status field on a WorkspaceBuild so that it's accessible on workspace.latest_build.status.

The frontend will massage the workspace status a little bit further to make the terms more user-friendly (such as started -> Running, canceling -> Canceling Action), but this will keep the logic that depends on implementation details on the backend.

Note that the frontend will still use the job's status directly in the timeline when #1677 is implemented.