Support for using `{n}` in the help message

[andreykaere]

Please complete the following tasks

• [X] I have searched the discussions
• [X] I have searched the open and rejected issues

Clap Version

4.4.6

Describe your use case

I want to be able to use this help message:

When this option is specified, the program will try to match the given
pattern with the filename and write extracted information to the
metadata.

You can use the following correspondence when writing your pattern
{n}  Artist <-> {a}
{n}  Title  <-> {t}
{n}  Album  <-> {m}
{n}  Year   <-> {y}
{n}  Track  <-> {n}

Default parser patterns are shown below and parsers tries each of them
in the given order:
{n}  1. {n} {a} - {t}
{n}  2. {n} {a} — {t}
{n}  3. {n}. {a} - {t}
{n}  4. {n}. {a} — {t}
{n}  5. {a} - {n} {t}
{n}  6. {a} — {n} {t}
{n}  7. {a} - {n}. {t}
{n}  8. {a} — {n}. {t}
{n}  9. {a} - {t}
{n}  10. {a} — {t}
{n}  11. {n} {t}
{n}  12. {n}. {t}
{n}  13. {t}

where first {n} are expected to be interpreted as \n and I want to have ability to "escape" other {n} to be able to see literally {n} in the output help message.

Describe the solution you'd like

To have escaping option to be used: for example {{n}} or \{n\} or something like that.

Alternatives, if applicable

No response

Additional Context

No response

[epage]

Note that we want to remove support for {n} (#3230). The main reason it still exists is because of our poor handling of markdown in doc comments for clap_derive. This is being tracked in #2389.

[andreykaere]

But for some reason clap replaces {n} even if I use builder pattern instead of deriving it. Any reason why is this the case?

P.S. Using verbatim_doc_comment doesn't change this behavior (although it's mentioned as a workaround in #2389).

[epage]

It exists in the builder because that was the original intended use case. Rather than partially back it out and then completely remove it, we've left it in as is until we can remove it.