Make tokenizer more strict for attribute syntax

For #4713. @dangoor 

In general, the tokenizer was already handling most cases of mismatched double-quotes correctly by returning an error. For example:

`<p style="></p><img src="foo">`

was fine; the tokenizer would see the value of `style` as `"></p><img src="`, then try to parse `foo"` as an attribute name, and fail because `"` isn't legal in attribute names. (It actually should have failed for another reason--see below.)

However, the case in #4713 was equivalent to:

`<p style="></p><img src="foo/bar">`

When the tokenizer saw the `/` while trying to parse `foo` as an attribute name, it assumed it was the beginning of a self-closing tag, and then just ate all the characters up until the `>`.

I added three cases (following the HTML spec) where the tokenizer should be stricter in order to make it more likely to fail when there are mismatched attribute quotes:

* in self-closing tag syntax, the `/` must immediately be followed with the '>', with no characters in between (not even whitespace)
* a quoted attribute must be separated from the following attribute name (if there is one) by whitespace (this should have been the reason for the first case to fail)
* there must be nothing in a close tag following the tag name besides whitespace (this isn't directly related to this case, but would make it even more likely that we would detect an error)

There are still cases where we could potentially get confused--for example, if there were an unclosed quote in an attribute value, the next quoted attribute value in the document happened to start with `>` or `/>`, and the rest of the tags around the mistake happened to balance out properly. This seems very unlikely, though, and I think there really isn't anything we can do about that since it could technically be a valid HTML document.