Expose flow state to the user

### Description

**TL;DR** Expose the current flow state in the FlowForge dashboard and allow the user to start/stop the flows without opening the editor.

**Use Cases**

1. User clones an existing project but wants to edit the flows before they start running. This will be implemented by #876, but without the flow state exposed in the FF dashboard the user doesn't have clear information on the project state. That issue is blocked until we resolve this one.

2. A user deploys a change that introduces an infinite loop in their flows. The editor becomes unresponsive as the process is tied up. They want to restart the Node-RED in safe-mode, or with the flows stopped so they can fix the issue and redeploy.
The current workaround is to add an env var `NODE_RED_ENABLE_SAFE_MODE` set to `true` in project settings then restart the project. That is not intuitive.

---

We previously revisited Project Lifecycle in https://github.com/flowforge/flowforge/issues/787, as it was needed to introduce the Suspended state properly.

However it didn't address a particular part of the lifecycle that Node-RED 3.0 introduced - the fact Node-RED can be running with the flows stopped.

## As-Is

At the moment, we have two high-level states (I'm ignoring the transitional states like 'starting', 'stopping' etc as this is more about the 'steady-states' a project can be in.

- **States**
- `suspended` - container not running, not being billed
- `running` - container running, node-red running, flows running

We currently provide the user the following actions from within FF:

- **Actions**
- `start` - moves from 'suspended' to 'running' state
- `restart` - restarts Node-RED inside the container. This is needed to pick any changes to project settings
- `suspend` - moves from 'running' to 'suspended' state

Inside the NR editor, the user has options to 'start' or 'stop' their flows.

If the user 'stops' their flows from within NR, we do not reflect that state in the FF dashboard for the project.

We also have 'safe mode' to consider properly. This is a special type of 'stopped' state inside Node-RED where the the flows are not running, but will be started automatically when the user deploys any change. The launcher will put Node-RED into safe-mode automatically if NR crashes too many times, too quickly.

So the full list of steady states needs to take into account both the container *and* flow state.

## To-Be

I propose we add a `stopped` state:

- **States**
- `suspended` - container not running, not being billed
- `running` - container running, node-red running, flows running
- `stopped` - container running, node-red running, **flows not running**

- **Actions**
- `start` - moves from 'stopped' to 'running' state (ie starts the flows)
- `restart` - restarts Node-RED inside the container. This is needed to pick any changes to project settings. *Also starts the flows if they were stopped*.
- `stop` - moves from 'running' to 'stopped' state
- `suspend` - moves from either `running` or `stopped` to `suspended`
- `unsuspend` - moves from `suspended` to either `running` or `stopped` depending on what state it was in when suspended.

```mermaid
stateDiagram-v2
Suspended
state old_state <>
Stopped
Running
Suspended --> old_state : unsuspend
old_state --> Running
old_state --> Stopped
Running --> Suspended : suspend
Stopped --> Suspended : suspend
Running --> Stopped : stop
Stopped --> Running : start
Running --> Running : restart
Stopped --> Running : restart
```

### Notes

To handle the second use case (infinite loop in flows), the user will want to 'stop' the flows. If the runtime is locked up in a loop, then the 'stop' request will fail. We need to handle that internally and do a more forceful restart of the NR process into the stopped state.