Fix the parser behavior for texts containing curly-braces when the Attributes extension is enabled

[xavierlacot]

The issue

As stated in #1035 (comment), the PR #986 , which introduced the ability to create valueless attributes using the Attributes extension, causes issues when a markdown document includes text strings that contain curly braces.

For example, the following markdown text

Elastic{ON} Tour San Francisco

is rendered by the official commonmark dingus as:

<p>Elastic{ON} Tour San Francisco</p>

The league/commonmark library with the "Attributes" extension enabled was used to render such markdown the same way until the commit 2138460. Since then, it renders this markdown as:

<p>Elastic Tour San Francisco</p>

which is obviously something we do not want.

What does this PR

This PR reverts the changes introduced in #986 and #1035 and adds more test cases, to show how to create valid boolean-attributes.

A section has also been added in the documentation to show how to write attributes that will be rendered as empty-value attributes in HTML.

[colinodell]

Thank you for the PR!

While I do like the simplicity of allowing {attribute}, I think it's entirely reasonable to revert that feature in favor of the more explicit approach that is less likely to collide with other user input.