Make a number of updates to schema processing, all of which fall under the
umbrella of issue #1163.  The individual issues addressed include:

* 1139 -- Properly handle OBSOLETE flag in schema elements.  The OBSOLETE flag
is now recognized when processing matching rules, attribute types, object
classes, name forms, DIT content rules, DIT structure rules, and matching rule
uses.  It essentially provides a way to "deprecate" a schema element so that
existing data that makes use of them will still be treated properly, but the
server will not allow newly-created elements to reference them.

* 1145 -- Consider updating X-ORIGIN to reference newer RFCs.  When the schema
configuration files were originally written, there were a number of references
to RFC 2252 and RFC 2256 that were updated in RFC 4512 and RFC 4519, among
others.  The X-ORIGIN extension for each element in the 00-core.ldif schema
configuration file should now reference the latest specification that contains
that element.

* 1146 -- Consider enforcing object class inheritance restrictions.  The server
will now ensure that abstract classes can only inherit from other abstract
classes, that auxiliary classes can only inherit from abstract classes and
other auxiliary classes, and that structural classes can only inherit from
abstract classes and other structural classes.  Further, all structural object
classes must include the "top" abstract class as the root of their inheritance
chain.

* 1147 -- Consider enforcing attribute type inheritance restrictions.  The
server will now ensure that a subordinate attribute type will have the same
usage as its superior type.  Further, the server will enforce that a
subordinate attribute type may be collective if and only if its superior type
is collective.  Due to the subjective nature of the "refinement" clause for
syntax inheritance, no check will be made regarding the syntax relationship
between a superior and subordinate attribute type.

* 1151 -- DIT content rule validation isn't handled correctly.  The server will
now allow attribute types to appear in an entry if they are included in the
required or optional attribute type lists for a DIT content rule even if those
attributes are not allowed by any of the entry's associated object classes.
Further, the DIT content rule validation process will now ensure that none of
the prohibited attribute types are required by the structural object class or
any of the allowed auxiliary object classes.

* 1158 -- Attribute syntaxes describing schema elements aren't strict enough.
Previously, in most cases that one schema element referenced another element
that was not defined (e.g., an object class allows an attribute type that is
not defined in the server schema), the server would ignore the unresolved
dependency.  The server will now fail to validate schema elements that depend
on other schema elements which are not defined in the server schema.
Similarly, there were cases in which the server did not properly validate that
an object class was of the appropriate type (e.g., for a DIT content rule,
there was no check to ensure that the structural object class was actually
declared structural, or that all of the allowed auxiliary objectclasses were
actually declared auxiliary).  The server will also fail to validate schema
elements with these kinds of problems.

* 1159 -- Incomplete attribute type usage constraints.  The server did not
properly ensure that COLLECTIVE attribute types had a usage of
userApplications, and that NO-USER-MODIFICATION attribute types had an
operational usage.

* 1164 -- Need more complete DIT structure rule validation.  The server did not
properly ensure that if an entry's parent was associated with a DIT structure
rule, that entry would only be valid if it was covered by a DIT structure rule
which listed the parent's DIT structure rule as a superior rule.

* 1165 -- Consider reduced name form and DIT structure rule checking.  The
server would often perform more schema validation than necessary for most types
of operations.  In particular, name form and DIT structure rule validation
should not be required for modify operations, and DIT structure rule validation
should also not be required for LDIF import operations since we cannot
guarantee that the parent will be accessible.