Group similar builds

We group builds by removing from the builds name two numbers which are delimited by whitespace or colon:
* `name 0 1` => `name`
* `name 0:1` => `name`
* `name 0/1` => `name`
* `name 0:1 ruby` => `name ruby`
* `name 0/1 ruby` => `name ruby`
* `0 1 name ruby` => `name ruby`
* `0:1 name ruby` => `name ruby`
* `0/1 name ruby` => `name ruby`

See merge request !6242

This reverts commit 575dc2b0d78b2680d6e5bb43f293c98d378b8733.

Because pipeline status could be changed for the builds in the next
stages, if we process next stages first, the current build would be
out of synchronized, and would need a reload for that matter.

Alternatively, like what I did in this commit, we could process the
next stages later (by using `after_transition` rather than
`around_transition`), and complete what're doing for the current
build first. This way we don't have to reload because nothing is
out synchronized.

Note that since giving `false` in `after_transition` would halt the
callbacks chain, according to:

https://github.com/state-machines/state_machines-activemodel/blob/v0.4.0/lib/state_machines/integrations/active_model.rb#L426-L429

We'll need to make sure we're not returning false because we don't
intend to interrupt the chain.

This fixes #22010.

After this fix, both pipeline events and build events would only show
up once.

rename Statuseable to HasStatus

## What does this MR do?

- Rename all instances of Statuseable in the codebase, to HasStatus
- Rename all files from statuseable to has_status

## What are the relevant issue numbers?

Closes #21103 

See merge request !6003