SSP-1668 Support case-insensitive query, result and data attrib values

Also some special handling for username case-sensitivity, reflecting
the existing special treatment of that property throughout PD.

Username case-insensitivity was the primary motivation for this patch,
but the solution was much more general.

All attribute values are still case-sensitive by default, preserving
legacy behavior.

Configure case-insenstivity on query attributes if you want searches
to be case-insensitive. If your underlying data layer is case
sensitive and stores values in non-canonical casings, you'll also
need to set corresponding data attribute case-insensitivity config.
Not all data layers will handle this equally well, though. If the
data layer does not support function-based indices you'll want to
prefer storing data in a canonical casing.

Configure case-insensitivity in result attributes if you want to
normalize in-application representation of certain attributes. This
is most useful for usernames.

Splitting query and result configuration in this way allows for
case-insensitive attribute search while preserving data-layer
attribute value casing. E.g. you may want case-insensitive search
on givenName but you don't want all those values converted to
lower case when returned to the application. (Note that uPortal's
JPA DAO (which is actually outside the PD DAO hierarchy) already
supported this for non-username attributes.)

Query and result attribute case-sensitivity is configurable for
subclasses of AbstractQueryPersonAttributeDao.

Data attribute case-sensitivity is configurable for subclasses of
AbstractJdbcPersonAttributeDao. This patch did not include direct
support for LdapPersonAttributeDao because the LDAP schema typically
specifies which attributes should be handled case-insensitively, thus
the data layer effectively solves the problem for us, assuming a
well-designed schema.

All case-sensitivity config is in terms of application- rather than
data-layer attribute names. This allows for configuration to be
consolidated, e.g. into one or more abstract parent beans, because
the sensitivity policy can be set once per application attribute
rather than once for every uniquely named data-layer attribute. It
also more accurately reflects the intent of the configuration, which
is to declare the global case-sensitivity assumptions the application
makes.