Fix for issue 2642 (ldif-diff doesn't detect differences in encoded values)

The fix has three parts.

1. Currently the code of ldif-diff does not take into account the syntax of the attributes.  Basically the comparison of values is a non-case sensitive String comparison.  In order to be able to take into account the syntax of the attributes a config file must be provided to LDIFDiff.  This is fixed by invoking _server_script instead of _client_script on the command-line scripts (ldif-diff and ldif-diff.bat).

2. There is a problem with the normalization in the org.opends.server.schema.UserPasswordExactEqualityMatchingRule class.  Currently the normalized value in the case of an encoded password is the lower-case version of the value.  For instance:

value: {SSHA}cJNE9kjr52rZmttLaIrl4bOelWfvlM3Luk4Q7g==
normalizedValue: {ssha}cjne9kjr52rzmttlairl4boelwfvlm3luk4q7g==

The fix consists on only normalizing the encoding tag:
value: {SSHA}cJNE9kjr52rZmttLaIrl4bOelWfvlM3Luk4Q7g==
normalizedValue: {ssha}cJNE9kjr52rZmttLaIrl4bOelWfvlM3Luk4Q7g==


3. If we load the configuration and we always use the schema check when reading the provided LDIF files, if those files are not compatible with the schema on the installation where they are being run, the ldif-diff will not work.  In order to keep the current behavior (and thus accept LDIF files that are not compatible with the schema of the installation) a new argument has been added to the ldif-diff command-line (checkSchema).  The user must provide this argument if a strict comparison of the values must be made.  Adding this attribute allows to keep the current 'tolerant' behavior of ldif-diff, however it makes the use of the command-line a bit more complex.  I personally think that having the possibility of running ldif-diff regardless of the schema overweights the problematic added complexity, but maybe someone disagrees (or has a better alternative than adding this argument).

The changes in LDIFDiff correspond to the new argument.