feat(qsa, flatten-tree): abstract Node and Element apis in virtual tree

[straker]

I wanted the abstraction layer on the virtual node to be consistent and predictable so you wouldn't have to look at the virtual node implementation to figure out what the thing was called you wanted. I went with prefixing all api names with element and then capitalizing the first letter. Someone suggested mimicking jQuery api names, but they don't have any api names for low-level properties like nodeType, and nodeName, which would mean an inconsistency in naming convention.

Qsa tests used a mock virtual tree, which made it really difficult to test changes to qsa that depend on the virtual tree implementation. So I changed it to use a real virtual tree and then added a test to ensure qsa does not look at the actualNode property (ensuring a DOM-less run).

Linked issue: #1552

Reviewer checks

Required fields, to be filled out by PR reviewer(s)

• Follows the commit message policy, appropriate for next version
• Has documentation updated, a DU ticket, or requires no documentation change
• Includes new tests, or was unnecessary
• Code is reviewed for security by: @WilcoFiers

[straker]

With hasClass we were now adding functions with logic, so I decided to create a VirtualNode
constructor function so we could have tests around the logic. I also moved the getter functions for isFocusable and tabbableElements to prototype functions so they could be part of the shared prototype rather than one off for each virtual node.

Resolved

Resolved

Resolved

[stephenmathieson]

LGTM, but I think this one needs another set of eyes. Maybe @WilcoFiers or @JKODU can also review?

[WilcoFiers]

One question, and we need the getters back. Sorry, that idea of using getters was mine, I'm not sure it was a good one, but we're stuck with it.

Resolved