Markdownlint: dashes-in-headings custom rule

[MaoShizhong]

Because

Markdownlint and VSC use GitHub's heading algorithm to generate fragments, which gives different results to Ruby on Rails' #parameterize method when dealing with isolated dashes (a dash group surrounded by spaces, used as a separator).

This leads to the TOP-valid fragment for ### Heading - Subheading triggering the MD051 rule, and the Markdownlint-valid fragment not matching the correct heading ID.

While we can use ### Heading - Subheading {#heading-subheading} for Markdownlint and VSC to pick up, this looks messy and just gives us an extra point of failure if we change the heading but forget to change the custom ID.

The solution is to enforce colons as separators, leaving other dash uses (like hyphens or CLI flags) in headings alone. Markdownlint and our web app will both convert ### Heading: Subheading and hyphenated-word to heading-subheading-and-hyphenated-word.

This PR

• Adds TOP011 custom rule for dashes in headings
• Provides test file demonstrating what headings are flagged and not flagged by this custom rule
• Provides TOP011 doc file
• Adds TOP011 to the custom rules array in the markdownlint config file
• Amends TOP001-TOP010 doc files to use colon separators in headings for consistency

Issue

Closes #28328

Additional Information

This problem was encountered in #28327

Pull Request Requirements

• I have thoroughly read and understand The Odin Project curriculum contributing guide
• The title of this PR follows the location of change: brief description of change format, e.g. Intro to HTML and CSS lesson: Fix link text
• The Because section summarizes the reason for this PR
• The This PR section has a bullet point list describing the changes in this PR
• If this PR addresses an open issue, it is linked in the Issue section
• If any lesson files are included in this PR, they have been previewed with the Markdown preview tool to ensure it is formatted correctly
• If any lesson files are included in this PR, they follow the Layout Style Guide

[MaoShizhong]

Edit: Changing the algo used for the website would probably be more disruptive by breaking any links that include fragments that would differ if we generated them using the github algorithm. So probably using this rule would be preferable.

---

@KevinMulhern would appreciate your opinion here. Was just chatting to Eric about alternatives to implementing this rule, as I just realised this rule won't cover cases like ### This / that being converted to #this-that by #parameterize in our app, and markdownlint using Github's fragment conversion algo which would convert it to #thisthat.

Was just wondering that as an alternative to this rule to cover only some of the mismatches in algos, whether we could nab the Github algo (adapted as necessary) and make a custom method in Rails to replace #parameterize. That'll sort out all discrepancies in link fragments between markdownlint and our website, without the need for a custom rule. Wondering if that might be a more complete solution while also not being too much work.

[MaoShizhong]

#28694 highlighted another issue with the discrepancy between MD051 using GitHub's section heading algo, and our website using #parameterize.

Closing since this PR will not be a sufficient fix - further discussion required.