Refactor Person and GuestPerson classes

[rsdoiel]

The structure of Person and GuestPerson behaves like GuestPerson is a subclass of Person. The Person class should be the parent and not sited to a specific database presentation or storage. A subclass would then be used for stored Person objects via the ORM. This will allow us to store a minimal class of users while allowing general access through the fact of having a Shibboleth/Basic Auth managed account.

Person class when instantiated holds a default user description with the uname assigned on instantiation (e.g. the value that Shibboleth passes as REMOTE_USER). It should contain the following attributes - uname, display_name, role. The person class would define a standard set of methods like has_role() these would return results based on the attributes held in the object instance.

A generalize function like person_from_environment() could then return a Person compatible object based on either the default Person class or the subclass where the attributes are populated via the ORM.

Ideally the server code should think all Person objects are the same but behind the scenes we only store rows in the SQL person table for specific people who require more than the minimum access.

The eventual goal is for people.py and people-manager to become a common package use across applications that we build for apps.library.caltech.edu.