Unique phases for suspended and stopped

# Summary

What change needs making?

For the workflow phase and node phase, we didn't implement a full workflow logic, e.g.

1. if we resume or stop a completed workflow, it should panic since workflow state machine wouldn't allow transform state from ``, see issue #8173
2. if we suspend a workflow, it will set suspend=true in the workflow status, but the phase is still be `Running`, I think it doesn't make sense, how about design a set of workflow primitives and use a single field to show the workflow state?

# Use Cases

When would you use this?

When we're planning to design a workflow system based on argo-workflow, we need to read the workflow state and take actions to run the workflow, therefore, we need to improve our workflow design. For now, it's too fragmented and not friendly to user.

---

**Message from the maintainers**:

Love this enhancement proposal? Give it a 👍. We prioritise the proposals with the most 👍.

Start by reviewing the current workflow and node phase handling, including the state-machine concern described in issue #8173. The issue provides no file or test entry point; work is complete only after the project agrees on workflow primitives or a single state representation and defines valid behavior for suspended, stopped, completed, resumed, and stopped workflows.

Written by the indexing model from the issue text.