UP-4321 PortalPersonUserDetails exposes IPerson.

Enhance `PortalPersonUserDetails` to expose the `IPerson` rather than just the username as a `String`. ([UP-4321](https://issues.jasig.org/browse/UP-4321))

This is intended to be useful to code that wants to use APIs that take an `IPerson` rather than a username abstraction as their argument.

Worries to have about this feature
---------------------------------------------

Historically there was hand wringing and fanciness about differentiating which code could get at the real `IPerson` `PersonImpl` and which code could only get at a RestrictedPerson.  This feature potentially exposes a real `PersonImpl` (through the `IPerson` API) more widely within the uPortal .war class loader.  I think the tradeoff is worth making -- that the realities of trying to restrict code's access to person information in that way are fragile and difficult, whereas the realities in embracing code running within the uPortal `.war` classloader as able to know more richly the user context in which is running are positive.

Where did this feature come from?
-----------------------------------------------

Coded this feature in the course of trying to filter Marketplace related portlets down to those `BROWSE`able by the user.  Now going in a different direction in implementing that feature such that I don't now anticipate using this commit for that, so rather than bundling this now-unrelated commit with that changeset, proffering it as its own change.  Still seems worth including this change towards `4.2` since `IPerson`s are such terribly useful things in the current codebase and being able to get the current user's `IPerson` from thin air is probably going to enable some refactoring to use this approach.