Extend qunit.dom() to accept an object with an elements property so external objects that have their own DOM querying implementation like page objects can be plugged into qunit-dom's assertion API.

This is based on a Discord discussion with @Turbo87, and is aimed at supporting my new and still very much WIP page object library (see the tests for a rough idea of the usage patterns), and also at supporting any number of extensions to qunit-dom's querying functionality like #864.

Some notes:

Why elementsDescription?

I chose the name elementsDescription rather than the more terse description to support page object implementations where the page object nodes are passed directly into qunit-dom. In this case, any properties read by qunit-dom need to be reserved for "internal use" by the page object implementation, disallowing users from using those names for child nodes. This seems reasonable for elements and element, but much less so for description. For example, using ember-cli-page-object's API (imagining that it were extended to plug into qunit-dom):

import PageObject from 'ember-cli-page-object';

const page = PageObject.create({
  imageTiles: {
    scope: '[data-test-image-tile]',
    image: { scope: 'img' },
    description: { scope: '[data-test-description]' }
  }
});

// fine
assert.dom(page.imageTiles.objectAt(0).image).hasAttribute('src', 'funnyCatPic.jpg');
// whoops, description is a reserved property name that `qunit-dom` expects to contain a string!
// So either `assert.dom(page.imageTiles.objectAt(0))` would get a description of `[object Object]`
// or `assert.dom(page.imageTiles.objectAt(0).description)` would get a description string passed
// to it instead of a page object
assert.dom(page.imageTiles.objectAt(0)).exists();
assert.dom(page.imageTiles.objectAt(0).description).hasText('haha, a funny cat picture, how original');

I'm definitely open to other ideas for how to expose this information to qunit-dom in a way that isn't overly likely to cause page object footguns.

<unknown> vs. <not found>

<unknown> was used for the assertion message when null was passed in as the target, but if a selector was passed in that didn't match anything, the selector string would be used. In the other assertion messages where the element was not found, <not found> was used. I couldn't figure out what value this distinction was providing (if any, maybe just an accident of how the code evolved?), so I couldn't figure out how to translate it to the DOMQuery abstraction, so I just eliminated it, meaning some of the assertion strings have changed (as you can see from the tests). If there's a reason to keep <unknown> I'm happy to discuss how to revive it.

documentation

As mentioned in the second commit, updating the documentation was a bit of a PITA mainly, I think, because of some limitations of documentation. I did try switching to generating the documentation off of the typescript so we don't have to hard-code the ExternalQuery documentation in documentation.yml, but then it generated a separate entry for each typescript function overload signature, which seemed less than helpful. Anyway, this is the best I could come up with but am happy to entertain other ideas.