Improve Markdown syntax highlighting

[chbk]

Release Notes:

• Improved Markdown syntax highlighting
• Added syntax scopes to themes

Changes to highlights:

Zed 0.174.6	With this PR

Changes to include the markup scope, conforming to Neovim, VS Code, Atom, and Zed itself.

• paragraph, indented_code_block, pipe_table: text
• # Heading: title -> heading.markup
• -, 1., >, |: punctuation.markup
• ```: punctuation.embedded.markup
• [1]: url.com, [link](url.com): link.markup
• url.com: link_uri -> link.uri.markup
• *italic*: emphasis -> emphasis.markup
• **bold**: emphasis.strong -> markup.emphasis.strong.markup
• `raw`: text.literal -> raw.markup
• ~~strikethrough~~: strikethrough.markup

# Heading

Some stylized text:
- `raw`
- *italic*
- ~strike~
- **strong**

> quoted

```python
print("some code")
```

1. Here is an ![image](image.jpg)
2. A [link](https://github.com/zed-industries)
3. And even a [referenced link][1]

[1]: https://zed.dev

| tables | are |
| --- | --- |
| properly | scoped |

Changes to themes:

• Add highlighting rules for the following new scopes, using theme colors:

  • heading
  • strikethrough

• Rename scopes that are no longer used in zed/crates/languages/src or zed/extensions to their new names:

  • punctuation.list_marker -> punctuation.markup
  • link_text -> link
  • link_uri, link.url -> link.uri
  • text.literal -> raw

[maxdeviant]

These selectors aren't going in the right direction.

We do partial matching on selectors, so we want them to go from less specific -> more specific.

So for this one it should be @emphasis.markup.

This would allow for it to be styled just by emphasis, but overridden by emphasis.markup.

[maxdeviant]

I have some reservations about the breaking changes (the selector renames) to the themes in this PR, as it will break downstream user themes.

It would be great it if we could make the improvements without including the breaking changes so that we can deal with them separately.

[chbk]

Should I prepend original selectors, and create a new PR to deprecate them in the future?

In this PR we'd have:
@title.heading.markup
@text.literal.raw.markup
@link_text.link.label.markup
@link_uri.link.uri.markup
@punctuation.list_marker.markup

[maxdeviant]

Should I prepend original selectors, and create a new PR to deprecate them in the future?

In this PR we'd have: @title.heading.markup @text.literal.raw.markup @link_text.link.label.markup @link_uri.link.uri.markup @punctuation.list_marker.markup

I have some ideas for how we can handle the breaking change, but for now I would just like for this PR to make the improvements that don't require renaming the selectors. Once those are in place then we can merge the additive/backwards-compatible changes and deal with the breaking changes separately.