Add initial support for a virtual attribute subsystem, and implement a few
different kinds of virtual attributes.  This commit addresses the following
issues:

- Issue #1475 -- General virtual attribute support
- Issue #539  -- Support for the isMemberOf virtual attribute
- Issue #544  -- Support for the entryDN virtual attribute
- Issue #1056 -- Support for the subschemaSubentry virtual attribute
- Issue #85   -- Support for the real attributes only control
- Issue #86   -- Support for the virutal attributes only control

In general, virtual attribute support consists of three parts:

- An implementation of the org.opends.server.api.VirtualAttributeProvider
  class, which provides the logic for actually generating the values, providing
  support for various kinds of matching, and potentially the ability to process
  search operations involving the virtual attribute that might not otherwise be
  indexed.

- The org.opends.server.types.VirtualAttribute class, which is a subclass of
  org.opends.server.types.Attribute and uses the virtual attribute provider to
  generate its values.

- The org.opends.server.types.VirtualAttributeRule class, which associates a
  virtual attribute provider with a given attribute type, and also with a set
  of criteria that controls which entries should have the attribute.


The virtual attribute rule currently supports the following criteria that can
be used to decide whether an entry should have a given virtual attribute:

- Zero or more base DNs.  If any base DNs are provided, then any entry which
  falls below one of those base DNs will be a candidate to get the virtual
  attribute.  If no base DNs are provided, then DIT location will not be taken
  into account when determining eligibility.

- Zero or more group DNs.  If any group DNs are provided, then any entry that
  belongs to one of the specified groups will be a candidate to get the virtual
  attribute.  If no group DNs are provided, then group membership will not be
  taken into account when determining eligibility.

- Zero or more search filters.  If any filters are provided, then any entry
  that matches one of the specified filters will be a candidate to get the
  virtual attribute.  If no filters are provided, then the contents of the
  entry will not be taken into account when determining eligibility.


In addition to that criteria, virtual attribute rules define a conflict
behavior, which controls how to behave when the entry already has one or more
real values for the attribute.  The conflict behavior can be
"real-overrides-virtual" (to only show the real values),
"virtual-overrides-real" (to only show the virtual values), or
"merge-real-and-virtual" (to show both real and virtual values).

The virtual attribute implementation has been designed so that there should be
virtually no performance impact unless the attribute needs to be returned to
the client or it is referenced in a search filter, and you can completely
disable virtual attributes if you don't need them.