Support a single qrexec service argument, available to qrexec policy

[marmarek]

The idea is to have control over qrexec policy not only based on service, but also based on some argument. This will allow to implement something like "allow service X, but only with argument Y". In most cases better idea is to have separate services or domains for that (for example multiple gpg backend domains), but there are use cases where it still can be a good idea. For example PV USB (#531) (USBIP variant) - "allow attaching this particular USB device" (creating separate services for that doesn't scale...).

As for implementation details, that argument will be encoded into service name, after + sign. This way it doesn't require major protocol change. Changes include:

• allow + in service name
• fallback to bare service name (with anything after + stripped) if full name isn't found - for both qrexec policy (/etc/qubes-rpc/policy/*) and qrexec target script (/etc/qubes-rpc/*).
• provide service argument to the target script in most convenient and compatible way

This means that target script may be named /etc/qubes-rpc/some.service, and it will be called for both some.service and some.service+argument (unless /etc/qubes-rpc/some.service+argument exists). Policy can be set for different arguments in appropriate /etc/qubes-rpc/policy/some.service+argument, then default policy in /etc/qubes-rpc/policy/some.service (most likely plain deny - empty file will do).

Target script will receive service argument as... its argument. Additionally there may be environment variable with it available, but it hasn't been decided whether it will be part of stable API.