MAC/do: Add support for scoped exec whitelist

[polyduekes_proton.me]

Summary

This change allows to let a mac_do consumer scope an executable
whitelist rule to a parent executable path in a manner such that
the child executable can only escalate it's privileges if a parent
executable exec's it.

it adds two literals,namely | and ~ to the exec=
field of the rule, the | literal scopes a path to a parent path
allowing it to escalate privileges if the parent path exec's it while
denying it to escalate privileges if it tried to do so in a standalone
manner while the ~ literal is meant to allow a scoped and allowed
executable to exec another executable without granting the scoped executable
the ability to escalate privilege if not executed by the parent path, such as
in a chained exec where /usr/bin/a -> /usr/bin/b -> /usr/bin/c, in such a scenario
specifying the ~ literal before /usr/bin/b in the rule entry would deny mdo b
from working while making sure that mdo a works properly

Signed-off-by: polyduekes <[e-mail]>

Motivation:
There are some legitimate cases where secondary execs need to be allowed, such as
poudriere jail -l which needs to execve /usr/bin/env,currently without the presented
change /usr/bin/env would be needed to be globally allowed in the rule's exec list in
order for mdo poudriere jail -l to work which has a downside that consequentially
that this would allow mdo env as well even if the user has no intention of allowing
env to be able to escalate it's privileges globally,this change aims to address that issue

Test Plan

The change is to be tested with executables that call other executables
with a followup exec.
The syntax for scoped exec is similar to as follow:sysctl
security.mac.do.rules='uid=1001>uid=0,gid=*,+gid=*(exec=/usr/bin/a|/usr/bin/b:~/usr/bin/b|/usr/bin/c)'
where /usr/bin/a is an executable that exec's /usr/bin/b and /usr/bin/b exec's /usr/bin/c

correct behaviour to be expected is that mdo /usr/bin/a would work, while mdo /usr/bin/b
is denied

Depends on D58012