Add functionality for mapping login classes typically found on BSD

[ghost]

This resolves #19

I have not tested building on other OSes that do not implement login classes, so it might be possible that we need to guard all of these changes with #ifdef HAVE_STRUCT_PASSWD_PW_CLASS

I would be happy to help fix this if so and also assist with any required documentation changes.

[ghost]

Confirmed now it still builds on Linux.

[arthurdejong]

Hi, thanks for your patch. This was suggested before and a similar patch was posted at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220379

Some problems with merging this change are described here:
https://lists.arthurdejong.org/nss-pam-ldapd-users/2017/msg00092.html

The main problem is that the protocol that is spoken between nslcd and the NSS module is difficult to change. The list post describe some alternatives but I'm not particularly happy with them either.

If you can provide something that at least would result in smooth upgrades (preferably also smooth downgrades) that would be ideal.

[ghost]

I was able to build nss-pam-ldapd with this patch, restart nslcd, and login with my test user which had a login class defined and it instantly worked. I did not have to restart any other processes on the system. Do you have examples of processes that would have issues and require to be restarted due to the NSS change?

software on my system that I can think of which might be relevant:

OpenLDAP
PAM stuff
sshd
nscd
sudo

If you can provide failure case scenarios we could look at ways to test this and fix it. I can't think of any because I don't believe I run any software that would be daemonized and have loaded the NSS module.