Fix a potential vulnerability if authproto_pam is setuid root.

There are many different PAM implementations out there, which I haven't
all tested. The PAM service name is used to build a path name, typically
inside /etc/pam.d, to find a service configuration file.

There's a possibility that in some PAM implementations, the service name
is not sanitized and could be used to traverse paths; as most PAM
clients are _not_ setuid and do _not_ let the caller specify the service
name (unlike xsecurelock), this alone wouldn't be a vulnerability per se.

And successful path traversal could e.g. lead to attackers obtaining
information about existence or nonexistence of files they can't see, or
possibly even reading part of a file (e.g. a PAM implementation might
spit out syntax error messages quoting parts of a file, either over
[possibly sniffable] syslog or to stderr; the latter would then allow an
attacker to run

XSECURELOCK_PAM_SERVICE=../shadow ./authproto_pam

to dump the root password hash.

Again, I'm not aware of any system where this exploit would actually
work - but as the PAM specs I have here do not describe what happens if
a PAM service name contains a slash (Linux PAM appears to use the
basename then), I've decided to just refuse any such names.