Cascade site deletions into site alias records

In SAK-14483 Peter expressed concern that allowing end users to specify site aliases would eventually drain the alias namespace. Although I think an argument could be made that aliases should be immutable and persistent, there is some precedent for using site deletion to trigger what are effectively site-scoped aliases: see SAK-33. Also, the patch attached to SAK-14910 gives non-super end users the ability to modify and delete aliases. If that patch or something like it is accepted, (optional) automated cascaded site alias deletion seems reasonable as well.

The attached patch (site-ref-alias-cascaded-deletion.diff) follows up on the above by introducing a new class in the site-manage-impl module: org.sakaiproject.sitemanage.impl.SiteAliasCleanupNotificationActionImpl. Upon initialization, this class registers itself as a "transient" NotificationAction and, if enabled, responds to SiteService.SECURE_REMOVE_SITE events by removing all aliases targeted at the deleted site's reference.

By default, the SiteAliasCleanupNotificationActionImpl bean is enabled and is configured to log and swallow exceptions reaching notify(Notification,Event). These behaviors can be modified by setting the following boolean properties:

enabled@org.sakaiproject.sitemanage.api.SiteAliasCleanupNotificationAction=true|false
propagateExceptions@org.sakaiproject.sitemanage.api.SiteAliasCleanupNotificationAction=true|false

Note that the default behavior is not consistent with historical behavior. But this can be changed easily.

As noted in the class javadoc, I chose to take the NotificationAction-based approach rather than the ContextObserver based approach since it was not really my intention to represent a new EntityProducer and implementing that interface is, frankly, unpleasant.