Don't try to survive scanning problems

This change does two things:
 * Fail scans instead of becoming confused.
   (The earlier solution preserved _mostly_ correct
   functionality on _most_ pages, but creates unsolvable
   problems on others - so we give up on this approach for now.)
 * Add minimal destroy functionality
> Typo, `inconsistend`.

Fixed.

> If this is in an if invisible condition, why does the comment say you see visible content?

The `invisible` flag which we test here cascades down from one our ancestors. The semantics is that we are in a part of the DOM which should not be visible at all. We know that from the fact that we have selected one of ancestors, tested it's string content, and it turned out to be empty. That's normal, for parts which are not shown. But then when going through the child nodes, we are now seeing something which seems to have a non-empty content (as tested using the selection API). (In the code, the relevant test is `cont.length` is non-zero.) That's totally wrong, and should not ever happen in an invisible sub-tree.

Of a node is hidden (for example, by display:none - but there are many other possibilities), then this _always_ triggers down. We can't un-hide a child node if the parent is hidden. And the selection API is (generally) a faithful representation of what the user actually sees: if something is visible, the content will appear in the string gained by the selection API; if something is invisible, it will be left out.

This is why it's completely against this contract that testing a sub-tree yields content, while testing a parent yields an empty string. This does not usually happen, except when testing the parent element actually fails for some reason. The most frequent reason is that we somehow fail to select it properly, because of a selection API error.