XdpAppInfo refactoring

[swick]

Contains a few commits from #1619.

• use the GInitable interface with pid and pidfd to create the various XdpAppInfo subclasses
• make registration a construction property for XdpAppInfoHost
• make testing XdpAppInfo subclasses possible by adding a testing construction property and creating mock objects based on new environment variables
• drop XdpAppInfoTest
• add new fixtures to control the exact XdpAppInfo the portal frontend will detected

Still a bit rough and needs some cleaning up, but I think the end result is a good improvement.

[GeorgesStavracas]

The "mess" the I mentioned in my PR is having to add private setters for private fields of the parent class. I ended up with similar diff and I still dislike it. Which is why I opted for the splitting up the properties, and handling the construction complexity in the xdp_app_info_*_new functions. This is similar to various internal constructors in GTK.

I like the tests this PR introduces, but I don't think the XdpAppInfo changes are worth it.

[swick]

At least when using pid and pidfd as construction properties, and then using setters in the initable_init, we get uniform construction via initable_new.

When using xdp_app_info_*_new to set different construction properties, what purpose do the properties serve? Compared with using setters as is done in this MR, it seems like a more roundabout way of setting the parent private data.

[swick]

Tried to minimize the changes to get the improved XdpAppInfo testability #1627

[jadahl]

When using xdp_app_info_*_new to set different construction properties, what purpose do the properties serve? Compared with using setters as is done in this MR, it seems like a more roundabout way of setting the parent private data.

Using construct properties is a common pattern used in GObject code bases to plumb things up the type chain without having to add private setters.