Drop privileges to user pelican if requested

[bbockelm]

This drafts out an approach to having the pelican server process run unprivileged after initial startup. Components:

0. This is enabled/disabled by configuration parameters, Server.DropPrivileges and currently defaults to false.
1. The configuration now tracks a new user object, the "Pelican" user (defaulting to pelican). This represents the target daemon user the process will be run as once the permissions are dropped.
2. The beginnings of marking the various configuration & runtime directories/files of the service as belonging to the pelican user.
3. Infrastructure to signal to the xrootd process to either send itself a signal or make a copy of the file descriptor.
4. Image build infrastructure for the new plugin. To make the final PR smaller, this item could be pulled out into a separate PR.
5. Finally, actually dropping the privileges to the pelican user after launch is almost complete.

TODO items:

• Open a separate issue to handle the RPM-side of the changes. We've now grown a new dependency on an XRootD plugin and need to get the OSG packaging in a similar condition.
• Actually test the signaling between pelican and the new xrootd plugin. I'm simply showing this as the draft of the approach so it can be handed off to @h2zh. I expect this is going to need bugfixes.
• More thorough investigation of file ownership.
• Write a unit test that, when run as root, will fork off a separate process and run a "federation in a box" with drop privileges enabled. Check the functionality of host certificate updates, shutdown signaling, and the ownership of directories is as expected.

[matyasselmeci]

Not a big fan of depending on a private API. If we absolutely need that class, we should get the developers to make it public, otherwise this is going to break when we least expect it.