Improve issue boards docs

- Add a mention od Milestone lists to the terminology section.
- Add links to the Milestone and Assignee lists.
- Style: split long lines.
- Style: add a divider if there's an image followed by a heading.
- Style: don't say "simply".
- Rearrange the Milestone and Assignee lists sections to reflect
  the order in UI.

Closes https://gitlab.com/gitlab-org/gitlab/-/issues/196779

doc/user/analytics/value_stream_analytics.md

@@ -69,7 +69,7 @@ Each stage of Value Stream Analytics is further described in the table below.
 
 | **Stage** | **Description** |
 | --------- | --------------- |
-| Issue     | Measures the median time between creating an issue and taking action to solve it, by either labeling it or adding it to a milestone, whatever comes first. The label will be tracked only if it already has an [Issue Board list](../project/issue_board.md#creating-a-new-list) created for it. |
+| Issue     | Measures the median time between creating an issue and taking action to solve it, by either labeling it or adding it to a milestone, whatever comes first. The label will be tracked only if it already has an [Issue Board list](../project/issue_board.md) created for it. |
 | Plan      | Measures the median time between the action you took for the previous stage, and pushing the first commit to the branch. The very first commit of the branch is the one that triggers the separation between **Plan** and **Code**, and at least one of the commits in the branch needs to contain the related issue number (e.g., `#42`). If none of the commits in the branch mention the related issue number, it is not considered to the measurement time of the stage. |
 | Code      | Measures the median time between pushing a first commit (previous stage) and creating a merge request (MR) related to that commit. The key to keep the process tracked is to include the [issue closing pattern](../project/issues/managing_issues.md#closing-issues-automatically) to the description of the merge request (for example, `Closes #xxx`, where `xxx` is the number of the issue related to this merge request). If the issue closing pattern is not present in the merge request description, the MR is not considered to the measurement time of the stage. |
 | Test      | Measures the median time to run the entire pipeline for that project. It's related to the time GitLab CI/CD takes to run every job for the commits pushed to that merge request defined in the previous stage. It is basically the start->finish time for all pipelines. |

doc/user/project/labels.md

@@ -164,7 +164,7 @@ Suppose you have the labels `workflow::development`, `workflow::review`, and
 applied, and a developer wanted to advance the issue to `workflow::review`, they
 would simply apply that label, and the `workflow::development` label would
 automatically be removed. This behavior already exists when you move issues
-across label lists in an [issue board](issue_board.md#creating-workflows), but
+across label lists in an [issue board](issue_board.md#create-workflows), but
 now, team members who may not be working in an issue board directly would still
 be able to advance workflow states consistently in issues themselves.