Add new module "pam_escalate.so" for non-root applications

For issue #7, I'm adding a new module "pam_escalate.so" that proxies authentication requests to another PAM stack in a setuid-root helper called pam-escalate-helper. Along with proxying the authentication conversation, it does some scrubbing and security checks to make sure that the caller only tries to do auth for their own user unless the caller is root.

A typical workflow would be:

1. An application running as a normal user, like gnome-screensaver, calls pam_start and pam_authenticate.
2. PAM loads pam_escalate.so and calls pam_sm_authenticate.
3. pam_escalate.so launches the subprocess pam-escalate-helper and sends a start message to its stdin.
4. Helper calls pam_start with some args from the start message and its own conversation function.
6. For each call to the helper's conversation module by other PAM modules like pam_krb5, it sends the message over stdout and receives a response from pam_escalate.so on stdin.
7. When pam_authenticate() finishes, the helper sends a finish message with the return code and exits.
8. pam_escalate.so receives the finish message and returns the code to the user.

I'm not done yet, but here's an implementation that actually works. I still need to add more comments, more unit-tests, and probably better security checks. I should have it mostly finished tomorrow, but I figured I'd send the first parts early.

At some point I'll break it out into another project, but I'm just trying to get this done quickly for now.
Just recording a different version of my answer from our meeting today:

If this is treated as not tightly-coupled to the cache, then it does need to always be euid=root. It's very similar to a program shelling out to /usr/bin/login. For the login process, it has no idea what PAM modules it's going to run or what privileges they need. There's no opportunity for a module to advertise that beforehand, and the module shouldn't make major changes to the process.

If we just had a helper for the cache like unix_chkpwd then you could easily root the system by pretending to be PAM and using the update action:

```
$ echo "NewPassword" | imaginary-cache-helper --action=update
$ sudo id
[sudo] password for someuser: NewPassword
uid=0(root) gid=0(root) groups=0(root)
```

With pam_escalate.so, we can actually trust the PAM stack, so we know for sure that the cache's update action only happens if the password has been verified by some other module (pam_krb5, pam_ldap, etc.).