fix: Smarter calculation of AT-SPI extents for the window

[mwcampbell]

This fixes the case where the window bounds aren't set at the adapter level, but the window's root object does have the bounds property. This currently happens in GTK 4 with Newton. Maybe I should extend the Newton AT protocol so the compositor can provide the window bounds, but this oculd also happen in other implementations with AT-SPI, and as always, we should make our code as resilient as practical.

This also handles the possible case where there are both kinds of bounds on the window; in that case, the adapter-level window size always constrains the node-level bounds, while the node-level bounds could possibly provide their own origin in window coordinates.

[DataTriny]

On the AT-SPI side: I think allowing implementors to set the root node's bounds in (presumably) screen space would add confusion since on most cases nodes are expected to have their bounds relative to the root window. Even then, which window bounds are we talking about? Are the decorations included or not?
On the Newton side: this seem to contradict a previous change (#278). As you described in your latest blog post, letting applications claim they have the focus is dangerous because focus is something global to the desktop and therefore multiple applications could fight over it. I think window bounds have pretty much the same characteristics. What if, for instance, an application claim that its window size is much bigger than it actually is? The window could then cover up a window from another application, with all the security implications.

[mwcampbell]

The intent is that if the root node object includes the bounds property, those bounds are specified relative to the inner window bounds set at the adapter level. For the actual AT-SPI adapter, both bounds are set by the application itself, but the node bounds could be provided by cross-platform code while the adapter-level window bounds are provided by a platform-specific component. In the case of Newton, currently the adapter-level window bounds aren't provided at all, though that could change. In either case, the node bounds property is never specified in screen coordinates, so it's consistent. Also, notice that the node bounds are constrained by the adapter-level window bounds, so a Newton application can't claim that the window is bigger than it actually is.

[DataTriny]

I still don't get why this would be useful, maybe I'm missing some context... I assume your Newton work is depending on this, so let's merge and see how it goes.