Improve Javadoc comments around conn schema use

Updated the Javadoc for the LDAPConnectionOptions methods related to
client-side use of server schema information.  The descriptions for
those methods now provide more information about the contexts in
which the client may use that schema information.

Avoid integer overflow in computeMapCapacity

Updated the StaticUtils.computeMapCapacity method to provide
protection against integer overflow for very large capacity values.

Remove txn/control restrictions from ldapmodify

The ldapmodify tool prevents using several arguments in conjunction
with the --useTransaction and --multiUpdateBehavior arguments.
One of those restrictions prevented using arbitrary controls in
conjunction with these operations, although certain specific
controls (available through control-specific arguments) were
allowed.  While the Ping Identity Directory Server does restrict
the set of controls that can be used in a transaction, other
servers may allow other sets of controls, and the set of controls
supported by the Ping Identity Directory Server may evolve over
time.  As such, the ldapmodify restriction preventing the use
of arbitrary controls when using a transaction or multi-update
operation has been removed.

Fixed a couple of LDAP SDK release note issues

Fix a minor release notes formatting issue

Update the release notes for the 4.0.5 release

Updated the LDAP SDK release notes in preparation for version 4.0.5.
The release notes now include a link to CVE-2018-1000134, and the
order in which some of the items were listed has been changed.

Improved ServerSet health check reliability

Updated the LDAP SDK's ServerSet implementations so that they can
perform bind and post-connect processing on the connections that
they create.  Previously, server sets were only intended to
establish connections, but not to authenticate them, and not to
perform any other post-processing on them (like using the StartTLS
extended operation to convert an insecure connection to a secure
one).  It was up to the caller (which was often a connection pool)
to perform that processing once it got the connection back from the
server set.

However, when asked to create a connection, a server set can be
given an LDAPConnectionPoolHealthCheck to use to check the validity
of the connection that it has created.  If such a health check was
provided, then it would have always been invoked on an
unauthenticated connection, which could cause problems against
servers that do not permit unauthenticated requests.  Further, if
some post-connect processing (for example, the StartTLS operation)
is needed on those connections, then the health checking would
have been performed before that processing had been completed, and
that could also lead to erroneous behavior.

With this update, server sets can now be created so that they
themselves perform authentication and post-connect processing on
connections before they make those connections available to the
caller.  More importantly, if provided with a health check, then any
appropriate authentication and post-connect processing will have
been performed on the connection before the health check is invoked.
This makes the health check more reliable because the connection
can be in a more useful state.  When a server set configured with
support for bind and post-connect processing is used in conjunction
with a connection pool, the pool will now delegate that processing
to the server set.  If the associated server set is not configured
to perform authentication and post-connect processing, then the
connection pool will still perform those tasks.

This update also fixes a potential problem that could lead to the
connection pool being unable to obtain a connection for processing
an operation.  Most server set implementations can be used in
conjunction with multiple servers, so that if it fails to establish
a usable connection to one server, it can try to obtain a
connection from a different server and shield the caller from the
connection problem.  However, this only applies to the portion of
the processing that is performed within the server set itself.
When the authentication and post-connect processing were left up to
the caller of the server set, the caller was more likely to
encounter a problem that it could not work around.  Now that the
additional processing is performed by the server set, its
resiliency can be extended to this authentication and post-connect
processing.

Update the release notes for the 4.0.3 release.

Updated the release notes to include the change between the 4.0.2
and 4.0.3 versions of the LDAP SDK.

Allow exporting a chain to separate files

Updated the manage-certificates tool so that the export-certificate
subcommand now includes a --separate-file-per-certificate argument
that can be used if both the --export-certificate-chain and the
--output-file arguments are also given.  If all of these arguments
are provided, and if there are multiple certificates to be exported,
then the file used to hold the first certificate will be the path
specified using the --output-file argument with ".1" appended to it,
the file for the second certificate will be the specified path with
".2" appended to it, and so on.  If the
--separate-file-per-certificate argument is not given, then all of
the certificates will be concatenated into the same file.

Fixed an interactive mode issue

Fixed an issue with command-line tools that default to interactive mode that
could arise if the tool is invoked without any arguments, but if it tries to
use a properties file referenced by an environment variable or JVM property.
If the properties file contained some but not all of the arguments needed to
invoke the tool, the command-line tool framework would still try to invoke the
tool with just the arguments from the properties file, which could result in
erratic behavior, unexpected errors, or uncaught exceptions.  The tool will
now launch in interactive mode to allow the missing arguments to be specified.