A table part arriving outside a table context implies a new table where a browser returns to the open one or drops the part

[jmanico]

Found while fixing #342 (#481), which leaves these unchanged.

TagBalancingHtmlStreamEventReceiver.prepareForContent opens implied elements from the current top of the stack before it checks what the top can contain, so a table part arriving in a container that is not a table gets a new table implied there, even when a browser would return to a table already open or ignore the part.

1. A row arriving inside a cell's div starts a new table inside the div; a browser closes the cell and adds the row to the open table:

<table><tr><td><div>x<tr><td>y</td></tr></table>
now:     <table><tbody><tr><td><div>x<table><tbody><tr><td>y</td></tr></tbody></table></div></td></tr></tbody></table>
browser: <table><tbody><tr><td><div>x</div></td></tr><tr><td>y</td></tr></tbody></table>

2. A row arriving inside a p with no table open gets a table implied inside the p, and a browser does not keep a table inside a p, so the output re-parses differently and is not idempotent:

<div><p>x<tr><td>y</td></tr>
now:     <div><p>x<table><tbody><tr><td>y</td></tr></tbody></table></p></div>
browser reads the output as: <div><p>x</p><table>...</table><p></p></div>

3. A row arriving after a bare col gets a table implied inside the colgroup, again not idempotent:

<table><col><tr><td>y</td></tr></table>
now:     <table><colgroup><col /><table><tbody><tr><td>y</td></tr></tbody></table></colgroup></table>
browser: <table><colgroup><col></colgroup><tbody><tr><td>y</td></tr></tbody></table>

The common cause is that the implied-elements step does not ask whether the element it implies can go inside the current top, and does not look for an open table to return to; a browser's "clear the stack back to a table context" does both. #481 added that return for tables it pushed out of the way, and the same walk, guarded by the table-scope boundaries (template, and foreign content once #461 lands), could serve here. Cases 2 and 3 are stability bugs, since the output is read back as a different tree; they are layout rather than safety, since nothing changes parsing context. Reproduced on main at fad01c1.

[jmanico]

Related, found while testing #481: the balancer treats </template> like any other end tag and looks for the template within default scope, so a table implied inside a template blocks it:

<template><tr><td>y</td></tr></template>z
now: <template><table><tbody><tr><td>y</td></tr></tbody></table>z</template>

A browser's </template> pops to the template regardless of what is open inside it (the "in head" rules generate all implied end tags thoroughly). Same cause in part, since the table was implied inside the template, but the end-tag scope for template is its own thing.