SSP-2460 Add LTI Provider capabilities

SSP actually acts as the "main" LTI provider, but for that to
work, SSP-Platform needed a few changes to its shared services.

Specifically, this commit introduces a new UrlBuilderService as
a shared Java API and addresses several technical issues which
prevented invocation of this an existing shared Java APIs from
SSP outside of portlet requests:

  1) ClassCastExceptions, esp from JPA/Hibernate - These calls now
  execute within uPortal's thread context ClassLoader by virtue of
  an additional pointcut added to persistenceContext.xml, and

  2) "The DAO Method that calls createNaturalIdQuery must be annotated
  with @OpenEntityManager or @Transactional" -
  JpaPermissionOwnerDao.getPermissionOwner() was correctly annotated,
  but the shared API impl - ApiPermissionsService - was invoking it
  via JpaPermissionOwnerDao.getPermissionActivity(), which was not
  properly annotated. Since we're using JDK proxies, the internal
  calls within that class were not proxied and the annotations on the
  former method were not honored. This must have just happened to
  work in other cases, e.g. Portlet requests, where the call stack
  passed through some other proxied class that also had the expected
  annotations. The solution was just to add the @OpenEntityManager to
  all the getPermissionActivity() and getPermissionOwner() overloads.

  3) Getting a reference to the impl - Previously only Portlet requests
  could get at the PermissionsService impl by looking up a special
  portlet context attribute. To support non-Portlet requests, there is
  a new static IMPL field on PermissionsService with which the portal
  registers the implementation at startup. As noted in the code comments,
  there is a certain amount of indirection involved there, partly to
  satisfy the Java compiler's requirements for interfaces, and partly
  to provide some room for additional security constraints in the
  future, e.g. applying SecurityManager policies on
  PermissionsService.IMPL.set().

NB that the changes to the shared APIs themselves means that this
commit bumps the platform-java-api version to 0.1.1-SNAPSHOT. So
SSP's dependency will need to be bumped as well.

The addition of UrlBuilderService affected the existing ad-hoc
point-to-point SSO mechanism (SsoController) to the extent that
that mechanism and LTI both now use the same target URL building
service.

The SSO ticket issuing mechanism, upon which SsoController and
LTI also both depend, has also been changed to:

  1) Invalidate redeemed tickets immediately, and
  2) Require a shared secret for ticket issuance

No. 2 is set as environment.build.sso.local.sharedSecret in
ssp-platform-config.properties. It defaults to the empty string,
which disables the feature. This affects existing deployments
using SsoController even if they're not using LTI. Going forward,
any deployer wishing to enable either SSO mechanism just needs to
set that config to some reasonably obscure value. If you're using
LTI, you also need to set ssp_platform_sso_ticket_service_shared_secret
on the SSP side to that same value.

All SSO requests, including LTI, are now redirected through Platform's
/Logout resource to ensure any existing session-user affinity is
cleared out.