Add serial-groups section to config reference

[rosieyohannan]

Description

Add details of the serial-group key to the configuration reference

Reasons

A link to a GitHub and/or JIRA issue (if applicable).
Otherwise, a brief sentence about why you made these changes.

Content Checklist

Please follow our style when contributing to CircleCI docs. Our style guide is here: https://circleci.com/docs/style/style-guide-overview.

Please take a moment to check through the following items when submitting your PR (this is just a guide so will not be relevant for all PRs) 😸:

• Break up walls of text by adding paragraph breaks.
• Consider if the content could benefit from more structure, such as lists or tables, to make it easier to consume.
• Keep the title between 20 and 70 characters.
• Consider whether the content would benefit from more subsections (h2-h6 headings) to make it easier to consume.
• Check all headings h1-h6 are in sentence case (only first letter is capitalized).
• Is there a "Next steps" section at the end of the page giving the reader a clear path to what to read next?
• Include relevant backlinks to other CircleCI docs/pages.

[nathanfishcircleci]

I believe right now we only support the individual job and not a group of jobs. We should be clear that this is specific for one job and that we will add "groups of jobs" in the future.

[rosieyohannan]

I believe right now we only support the individual job and not a group of jobs. We should be clear that this is specific for one job and that we will add "groups of jobs" in the future.

Does this work: "The serial-group key is configurable per job. It is not possible to configure the key for a group of jobs at this time."

[Fernando-Abreu]

We should note that if jobs with the same serial-group key within the same project have lower pipeline numbers, they will be skipped if a job from a higher pipeline number has already been executed.

cc: @nathanfishcircleci @liamclarkedev

[liamclarkedev]

I agree, that might even deserve its own subsection or somehow highlighted as an important detail.

Something along the lines of:

Serial groups are started in order of joining the queue but are accepted based on pipeline number, if a group is currently waiting/running and another group in the same project attempts to join the queue with a lower pipeline number, it will be not_run to maintain order integrity.

If there are no serial groups waiting/running, a pipeline with a lower number can start, such as restoring back to a previous pipeline via a rerun workflow.

[rosieyohannan]

We can add a caution section