SSP-1267 Provide user notification of JavaScript disabled
SSP-1767 Allow version information to degrade gracefully

This is a cherry-pick of the commit originally attached to pull
request #192, with very minor tweaks to adjust JS equality tests on
the 'toggle' var.
SSP-1809
ESL permission and confidentiality level adjustments
SSP-1892 Banking style login impl

* timeout driven by SSP PROPERTY (ssp-config.property) client_timeout
* timeout only active when user is logged in
* confirmation will be asked for when timeout occures in case end user
is still referencing information on the current screen
SSP-1892 Banking style login impl - remove logging
SSP-1888 Refactor most Maven filtering to runtime config

Everything that was previously set in ./filters/local.properties and
thus injected into the application at build time can now be set in
any number of other files and thus be evaluated at runtime, most
notably {SSP_CONFIGDIR}/ssp-platform-config.properties.

Defaults which were previously in ./filers/local.properties are now in
uportal-war/src/main/resources/properties/ssp-platform-config.default.properties.
The only file which is still eligible for build-time property
placeholder resolution is
uportal-war/src/main/resources/properties/build.properties which is
specifically intended to reflect attributes of the build.

Historically, uPortal did evaluate some configuration at runtime.
For example: rdbm.properties, security.properties, and
portal.properties were all loaded by a
PropertySourcesPlaceholderConfigurer and could thus have their values
injected into Spring Bean definitions. Additionally, components
such as InitialSecurityContextFactory and PropertiesManager would
themselves read and expose subsets of properties in those files via
various APIs. The latter components would not, however, participate
in the same recursive property placeholder resolution that
PropertySourcesPlaceholderConfigurer supports. This patch fixes that
asymmetry.

Note that while the PropertySourcesPlaceholderConfigurer still
errors out during its initialization if any Spring Bean definitions
contain unresolvable placeholders, the dependencies from
PropertiesManager and other components that read properties files
directly are such that they will continue to behave as they have
historically and simply echo unresolved placeholders.

Tests are all in QueryablePropertySourcesPlaceholderConfigurerTest,
which is sightly overbroad in that in also tests
PropertiesManagerInitializer, but this was done because all the
tests are really focused on integration tests of the new capabilities
introduced by the former.

Some config files still don't participate in runtime property
resolution at all, notably PAGSGroupStoreConfig.xml.

This patch also moves the 'CAS Validate Filter' configuration out of
./uportal-war/src/main/webapp/WEB-INF/web.xml and into
./uportal-war/src/main/resources/properties/contexts/mvcContext.xml.
This was done to allow that configuration to participate in runtime
property placeholder resolution. Unfortunately, we could not use the
standard DelegatingFilterProxy by itself because some of the
config being set on the Filter has to come from FilterConfig and
can't be set using simple Spring Bean properties. The workaround is
DelegatingFilterProxyBean, which allows a Spring-configured Properties
collection to masquerade as name-value config pairs on a FilterConfig
instance.
SSP-1888 Restore default platform db name (ssp)
SSP-1909 Generate build revision in the absence of .git dir

Manifest and build.properties will fall back to a timestamp if
git is not available.
SSP-1881 harmonize user_name lengths
* Harmonized up_person_dir.user_name to varchar(50)
* Harmonized up_user.user_name to varchar(50)
* Harmonized up_sso_ticket.user_name to varchar(50)
* Harmonized up_raw_events.user_name to varchar(50)
SSP-1888 Remove assertion that requires SSP_CONFIGDIR to be unset

Looks like we don't actually need this because the default property
source ordering in StandardEnvironment is different than what I
thought... JVM properties are preferred over system env vars. So
as long as tests always set the location of SSP_CONFIGDIR as a
system property, our tests should be fine... which they do seem to
be.
SSP-1978 Inject ApplicationContext into PortalPreAuthenticatedProcessingFilter

Avoids problems when initializing that class from the uP shell. In that
usage, PortalPreAuthenticatedProcessingFilter was (by way of its
collaborators) asking PortalApplicationContextLocator for the current
ApplicationContext, but the latter was still being initialized, which
PortalApplicationContextLocator believed to be an error.
[maven-release-plugin] prepare branch ssp-rel-1-4-patches
[maven-release-plugin] prepare for next development iteration
NOJIRA Bump SSP dependency version
SSP-1982 Update SSP clientTimeout response format expectations

Previously was getting a raw int, now gets a JSON object.

Also now defaults to the server-side default timeout if the
clientTimeout API errors out for whatever reason.
SSP-1988 Send force_platform_session_keep_alive=1 when poking SSP API

Forces the SSP API to dirty the platform session when the client-side
inactivity timeout has expired but the user then indicates that she
wants to keep her session alive. SSP session dirtying should happen as
part of the servlet container's normal request handling.
NOJIRA Add license headers
NOJIRA Update NOTICE file
[maven-release-plugin] prepare branch ssp-rel-1-5-patches
[maven-release-plugin] prepare for next development iteration