Clean up build system integration for Wayland security contexts

[smcv]

Follow-up for #4920. cc @emersion

• build: Link Wayland code into full libflatpak-common only

  This is only needed in flatpak-run-wayland.c, so we don't need it when
  linking ancillary daemons that don't need any of flatpak-run, such as
  the portal, session helper, system helper and OCI authenticator.

• build: Generate Wayland glue code as private

  The code argument to wayland-scanner is deprecated in favour of
  private-code, which marks the symbols as private, avoiding them
  leaking into the ABI of libflatpak.so.0.

  private-code was new in wayland-scanner 1.15, which is available in
  relatively old LTS distributions like CentOS 7, Debian 10 and
  Ubuntu 18.04, and is much older than wayland-protocols 1.32.

[emersion]

LGTM

[smcv]

For simplicity, I've only done this in the recommended Meson build system

Or we could just say that enabling Wayland security context support requires a halfway modern wayland-scanner (for context, Debian 10 had a new enough version, and is already EOL), and check for >= 1.15 as a minimum.

This feature already requires modern wayland-protocols, which old distributions aren't going to provide anyway.

I'm not intending to implement a version-conditional in Autotools because Automake syntax is so unpleasant to write, and because we should delete the Autotools build system before very long anyway.

[emersion]

Yeah, I think requiring new enough wayland-scanner is perfectly reasonable and would be simpler.

[smcv]

Yeah, I think requiring new enough wayland-scanner is perfectly reasonable and would be simpler.

Done, and yes it's simpler.

[smcv]

@emersion, does this still look good to you?

[emersion]

Sure