This is vs #12059, which changes the semantics of Dogtail so that
nodes are searched for on Dogtail::* object creation.

Refs: #12059

This reverts commit 75449088.

I need the test suite working to release 3.0~beta2, and it's been quite broken
on feature/stretch since the merge of test/12059-dogtail-optimizations.

refs: #12305

This reverts commit cf44cb39.

This didn't improve reliability.

The .click() method actually looks up the coordinates of the element
and then clicks those coordinates. The 'press' action directly causes
a "click" event that cannot be lost.

The affected part has been failing quite regularly on Jenkins,
presumably because the GUI isn't finished loading at the time, so the
coordinates we end up clicking on (with .click()) are the wrong ones.

... to significantly improve Dogtail's performance by saving state and
reusing it between Dogtail commands.

This is a massive commit, and it changes the semantics of the creation
of Dogtail objects. Previously they just created the code that then
would be run once an actionable method was called (.wait, .click etc),
but now it works like in Python, that Dogtail will try to find the
graphical element upon object creation.

Will-fix: #12059

This is very useful together with --interactive-debugging for learning
the role of some node you've found.

If the remote shell times out while running the dogtail script, this
cleanup will try to use the shell when it is dead, resulting in another
call that will time out. Since nothing is written to stdout, this may
result in Jenkins aborting the whole run due to this extra timeout.

Besides, we don't really care if potentially hundreds of scripts are
littering the guest's /tmp.

Now Dogtail prints "a rectangle around a Node when an action is
performed on it", which makes captured videos more helpful for
debugging.

We depend on the exact output of stdout sometimes, so if Dogtail writes
to it we get in trouble.

Now that we don't see the contents of these scripts when they are passed
through the remote shell, let's at least log the contents of failing
scripts.

... like reading a file, and writing or appending to a file. Now we can
read/write *any* characters without worrying that it will do crazy
things by being passed through the shell, as was the case before.

This commit also:
* adds some better reporting of errors happening on the server side by
  communicating back the exception thrown.
* removes the `user` parameter from the VM.file_* methods. They were not
  used, any way, and simply do not feel like they fit. I think the only
  reason we had it initially was because it was implemented via the
  command interface, where a user concept makes a lot of sense.

Will-fix: #6304

I'm not confident in any code checking for the absence of an addon
without having an anti-test checking that the same code can detect the
presence of some other addons -- then we might as well verify that the
list is exactly what we expect.

If the method is called in a try_for and is aborted, we'll try another
remote shell call in the ensure block, and this is prone to cause a
deadlock. Let's avoid this at the cost of offering less guarantees about
the cleanup, which is non-essential any way.

Due to how our remote shell works, we always get an extra newline.

This field will be checked often, I suspect.

It's actually a property of the dogtail object we "wrap". It was just
added by mistake.

Dogtail's stdout can contain other stuff, like debug logging, so let's
match the type of lines we are looking for.

The ScriptProxy part was a remnant from the time when I was still
concidering supporting Dogtail's procedural API, but it's now clear
that it will be too hard and not offer anything beyond the Tree
API. Also, the `interact` + block idea was from this time, and also
from a part of rewritten Git history where each use of the Dogtail
class instance inside the? `interact` block built up a single script,
that then was executed. However, since you can mix-in other calls
(e.g. to Sikuli) that may expect that a change already has happened,
that seemed like a bad approach.

So, let's KISS and simply settle on the classes Application and Node,
roughly reflecting those classes in the Tree API. The diff might look
scary, but it just moves code around, and removes some confusing
parts.

I've seen instances where `config.searchShowingOnly` is set multiple
times, which makes sense -- we add it for each component.

If this idea turns out working well, this should be upstreamed.

This provides a simple interface for generating python code, sending
it to the guest, and executing it.

Refs: #10721