Communications handbook is the SSoT for dates, time, timezones; introduce "communicating dates and time" section

Why is this change being made?

This MR aims to clarify the single source of truth for communicating dates and times in our handbook.

Why?

1. Confusion between GitLab handbook (SSoT) and remote playbook (not SSoT)
2. Duplication in engineering handbook (not SSoT) for UTC, communications handbook defines when UTC is being used (SSoT)
3. Ensure that the tools and tips handbook helps with Google calendar settings, macOS tools, etc.
4. Increase readability in the Communications handbook, and create a new section "communicating dates and times". Note: I often see this question being asked, and a direct anchor and heading helps with pasting a URL.

Note: The long list with different items in the writing style section needs more grouping to increase readability. I won't add more changes to this MR, as otherwise the diff cannot be reviewed efficiently.

Direct Review app URL

Changes

The changes are split into separate commits for more transparency, rather than creating a single large commit.

1. Remove the engineering handbook section for UTC timezones
2. Update the communications handbook based on the included recommendations for UTC, and PT
3. Introduce a section in "writing style guides" called "communicating dates and time"
4. Sort the bullet points, and group them with UTC (engineering, etc.) and tips, as well as PT and tips
5. The section was introduced in !83598 (diffs) and aimed to be corrected in !105619 (diffs) - merged the content changes, and added them in

Relations

• Requires Update tools & tips handbook as SSoT for timezo... (!106971 - merged) (tools and tips handbook SSoT)
• Duplicates Clarify that GitLab's primary timezone is Pacif... (!105619 - closed) (fix remote playbook)
• Relates to We should have a standard date and time format ... (!83598 - merged) (change remote playbook)
• Relates to !73805 (comment 553022515) (discussion)

Author Checklist

• Provided a concise title for this Merge Request (MR)
• Added a description to this MR explaining the reasons for the proposed change, per say why, not just what
  • Copy/paste the Slack conversation to document it for later, or upload screenshots. Verify that no confidential data is added.
• Assign reviewers for this MR to the correct Directly Responsible Individual/s (DRI)
  • If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the Maintained by section on the page being edited
  • If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies
• If the changes affect team members, or warrant an announcement in another way, please consider posting an update in #whats-happening-at-gitlab linking to this MR
  • If this is a change that directly impacts the majority of global team members, it should be a candidate for #company-fyi. Please work with internal communications and check the handbook for examples.

---