Add limits.d file generation to PipeWire and enable it by default

This MR does two things: fixes indentation in src/modules/meson.build (sorry for the churn) and adds limits.d file generation using mostly limits from the PipeWire documentation. Because the default memlock is not sufficient for real world use, I have included that as well.

It might be worth reconsidering if we really want rtprio 95 and nice -19 like we currently advise (same as the most common but possibly never properly scrutinized jackd limits.d, I believe). The memlock for the pipewire group is probably okay, though, unless we want to make it unlimited to prevent Ardour popping up a warning message box on the first run. From that I gather that the only purpose to have any limit at all is probably to attempt stopping a benign but buggy client from causing an accidental OOM (or something similar in effect to that).

As it stands right now, this MR will tread into the domain of distros by changing the default memlock for PAM users, so I'll explicitly raise awareness of distro maintainers to give them a chance to notice and react to this before it might get merged:

CC: @heftig (Arch), @daissi (Debian), @thesamesam (Gentoo), @K900 (NixOS contributor), @XRevan86 (OpenSUSE)

I guess I should explain why memlock should be multiple of 64. It's because it must be a multiple of the page size (as well as maybe another number like 16 but I do not exactly recall the details). And as you might be aware AMD64 architecture is, I believe, in the process of transitioning to 64k pages like pretty much all other architectures, so it makes sense to future-proof now by picking an memlock value that is a multiple of 64.

Update: after talking with Wim and having a thought about it, I have realized that the whole default memlock value is a red herring, because ultimately a bad client can always cause an OOM situation and the only difference is that having high memlock can either make it happen more rapidly or maybe try playing with the kernel OOM and systemd-oomd handling to keep the system thrashing or near OOM while not triggering an effective response. However such issues can be solved by better tooling and handling of malicious clients/users and those concerned about such attacks should instead work towards that. Turns out literally just months after I had tried to push the change inside Gentoo, the Linux kernel limit was raised to 8192 kilobytes making the default memlock value much ado about nothing.