Store element's found method

[vinocher-bc]

Store element's found method values, so it can be used to check if the element still exists. This allows a method like element.waitForNonExistence() to be implemented, to handle cases where the id may be reused by the Accessibility provider after an element is deleted.

[tristanlabelle]

I think this functionality needs to be implemented at a higher layer:

• There could be any number of ways to look up elements that don't fit within the foundUsing/foundUsingValue model, for example asking for the currently focused element, or asking for descendants of an element.
• This makes a child item (Element) know how to lookup itself, which is an inversion of layering as normally something else like a session or an ancestor element will provide a way to lookup the element.
• This adds extra state that is not represented in the webdriver protocol, and this project should remain as much as possible a direct mapping of that protocol.

I believe the intent is to replicate XCUITest functionality, but webdriver is a lower-level protocol and it may be that we need an intermediate layer to achieve this if we can't currently do it with our Arc UI testing abstractions.

[tristanlabelle]

The original query might also have had a startingAt value, so immediately rerunning the query using foundUsing and foundUsingValue would not return the same result.

[jeffdav]

I agree this feels like the wrong solution. We've discussed implementing XCUITest as a layer on top of this, which is probably the right solution.

[vinocher-bc]

• There could be any number of ways to look up elements that don't fit within the foundUsing/foundUsingValue model, for example asking for the currently focused element, or asking for descendants of an element.

Yes, this approach has holes, and will be abandoned.