Misleading closing tag optionality and nesting information in <h1>...<h1> example in readme

[myfonj]

superhtml/README.md

Lines 43 to 47 in 93a0fa9

	This will still be reported as an error by SuperHTML because otherwise the following snippet would have to be considered correct (while it's most probably a typo):
	```html
	<h1>Title<h1>
	```

h1's closing tag is not optional per spec, so telling that <h1>a<h1>b would have to be considered correct is misleading: no validator would consider such construct correct.
Spec defines the error recovery here through strict rules of what given element can and cannot contain, effectively preventing nesting so producing two sibling headings, but it's really just the error recovery.

Paragraphs and list items, on the other hand, do have optional closing tags, and it would be neat to finally have HTML language server that really reflects that and at least does not lie in DOM breadcrumbs (see: microsoft/vscode-html-languageservice#63). Marking <p>a<p>b as error is also misleading, but understandable, and definitely better than the misinterpretation VSC LS does. But again, real HTML parser conformance in HTML LS would be pretty much appreciated.