Add an attribute for user applications to run other applications

[0xC0ncord]

This addresses the issue raised in #365. With the advent of systemd --user support, we should support users running various applications through user units and other means. The problem is that any other such applications normally started by a user that transition to their own domain (i.e. user_systemd_t) do not have the proper permissions to run other applications.

Many applications' policies have their own way of granting run access to users. Some policies grant access directly with myapp_domtrans, myapp_run, or by granting an attribute. I think the best way to do this would be to streamline all such interfaces and templates to take exactly 3 parameters: the role prefix, the role, and the type of the user domain. This way we can have a single "proper" way to declare interfaces and templates like this, and we can ensure that calls to things like screen_role_template have everything they need.

In this PR I have only modified apache and screen to use this approach, and they are now using the proposed attribute for user application run access. I am opening this PR to hopefully get some early feedback on this approach, as the final result of this effort may be quite large.

This is a two-part PR. This PR addresses adding the required infrastructure for this feature, while the upcoming second PR will hook up this infrastructure into the application policies to support it.

This PR only adds the aforementioned attribute, the interfaces required to support it, and assigns it to the $1_systemd_t and $1_wm_t domains.

[pebenito]

I'm not sure where you are with this due to the weird github timestamping, but at a minimum, there are CI errors.

[0xC0ncord]

I'm not sure where you are with this due to the weird github timestamping, but at a minimum, there are CI errors.

I have a lot of local work that I haven't pushed yet. It will likely be a little bit more time before I think it is ready for review, so I am OK with closing this until then if you'd like.

[pebenito]

You can set the PR to draft and leave it open.

[0xC0ncord]

This is at the point now where every *_role() call I could find by the user domains has been reworked, and just needs some review and tuning to determine exactly what permissions and how those permissions should be granted to $1_t and $1_user_exec_domain. Initially I wanted the exec domain attribute to only be used for transition access, but there are a few edge cases where it might make sense to grant additional rules to be able to manage the applications' data.

As an aside, $1_user_exec_domain might need to be renamed, because user_user_exec_domain for the unprivuser is confusing.

[0xC0ncord]

After some discussion, I have decided to split this PR into two parts. This PR will address the infrastructure needed to support this feature, and the upcoming second will support actually hooking up this infrastructure into the applications. I think this part is finally ready for review.

[0xC0ncord]

Sorry, I forgot to change systemd_user_app_status() to a template in my last push. Corrected just now.