Add Set<NotificationState> to NotificationEntry to track things like New, Complete, and Favorited

https://issues.jasig.org/browse/NOTIFPLT-47

This changeset introduces the concept of states to Notification objects and refactors the FAVORITE feature to become a state.
@jameswennmacher -- I think this idea is workable and also that it adds value to some scenarios -- e.g. modeling related collections of mutually-exclusive states ('incomplete' vs. 'complete') -- but I also think it's another level of complexity.  Now I have to define StateType objects in addition to State objects.  So of the 2 collaborators that are commenting on this enhancement, one (@jameswennmacher) wants some thing more complex, and the other (@apetro) wants something less (he proposed simply Strings).

Here's a time-lapse breakdown of how I see states unfolding for an example NotificationEntry...
* (possibly... not sure yet) CREATED is *assigned* at time of issue
* NEW is *assigned* at time of issue
* NEW is *removed* the first time a user views it (reduces the count in the NotificationIcon portlet)
* FAVORITED is *assigned* when a user favorites it (duh)
* FAVORITED is *removed* when a user un-favorites it
* COMPLETED is *assigned* -- if applicable -- either by the user (if allowed) or by the back-end-system upon completion
* (possibly... not sure yet) ARCHIVED is *assigned* when (based on some logic TBD) it is moved from the Current Notifications list to the Archived Notifications list

@jameswennmacher -- as I write out these examples, I'm learning that I prefer the past participle version of the verb for naming states (e.g. 'CREATED' vs. 'CREATE' and 'ARCHIVED' vs. 'ARCHIVE')

So I see states being added to the collection (and rarely removed) in the lifecycle of a notification.  I don't see *a very common case* for one state being added as another is removed atomically.