Incorrect close/shutdown order in RepositoryServlet.destroy()

The RepositoryServlet.destroy() method closes the repository before unregistering its service.

As result, service trackers of the repository service, like the (new) HstContextLoaderListener (in nother or the same webapps) will cause exceptions being logged when trying to logout their repository sessions.

Furthermore, the DbLockManager which is managed and destroyed together with the repository, will need to force interrupt outstanding locks (which may fail/take a long time) while typically their threads can (or should) be more elegantly stopped by first unregister the repository service, as those threads/jobs typically are managed through service trackers thereof (like, again, the HstContextLoaderListener which then already/first will stop its Spring context).

Fix is trivial, just a proper reordering of the close/shutdown steps within th RepositoryServlet.destroy(), with closing the repository as (almost) last step.