[#1172] Refuse a second check-references-filter-criteria value for an attribute type, and enforce all the filters of a configuration that already has one (#1174)

Fixes #1172

## Problem

`ReferentialIntegrityPlugin.applyConfigurationChange` stored each
`check-references-filter-criteria` value with
`newAttrFiltMap.put(attrType, filter)`, so a later value for the same
attribute type overwrote an earlier one, while the validation checked
each value on its own and accepted the configuration. Which filter was
enforced depended on the sort order of the normalized values: the one
that sorts last won. Affected pairs: the same spelling (`manager:(a)` +
`manager:(b)`), a name and an OID or alias of the same type (`manager` +
`0.9.2342.19200300.100.1.10`), and, since #1158, a space before the
colon (`manager:(a)` + `manager :(b)`).

## Fix

The approach follows #1118 in the same plugin: refuse what is being
configured now, load what is already stored.

- **Enabling the plugin or changing its configuration** is refused when
two values name the same attribute type (compared as `AttributeType`, so
by OID): new `ERR_PLUGIN_REFERENT_DUPLICATE_FILTER_CRITERIA_133`, one
reason per attribute type, naming the attribute and all of its values.
- **A configuration already stored with such values** is still loaded
when the server starts, with
`WARN_PLUGIN_REFERENT_DUPLICATE_FILTER_CRITERIA_134`, and the filters of
one attribute type are combined in an AND filter: a reference has to
match all of them. Refusing it would stop the plugin from loading,
including the delete and modify DN clean-up; keeping "last one wins"
would keep an arbitrary choice.
- **Disabling a plugin loaded with a warning** is accepted, for this
case and for the #1118 one: a disabled configuration is checked only for
what loading it needs, as `PluginConfigManager` does, and enabling it
again is still refused.
- `isConfigurationAcceptableIgnoringCheckReferencesPluginTypes` is
renamed `isConfigurationLoadable`, since it now lets through both the
#1118 and the #1172 cases.
- The property description (configuration XML) and the Developer's Guide
(`chap-groups.adoc`) say that an attribute has one filter, that several
criteria go into one AND filter, and that a second value is refused
while the plugin is enabled. The XML has no `(&…)` example: the
description goes into the generated Javadoc of `opendj-config`, where
`&` fails doclint (`bad HTML entity`).

Message ordinals 133–134 in `plugin.properties`: no other open PR
changes that file.

## Tests

`ReferentialIntegrityPluginTestCase`, each for the three pairs above
(`manager:(employeeType=manager)` with `(description=approved)` as
`manager:`, as the OID, and as `manager :`):
- `testDuplicateFilterCriteriaIsNotAcceptable`:
`isConfigurationAcceptable` is false, with one reason naming `manager`
and both values.
- `testDuplicateFilterCriteriaIsLoadedWithWarning`: `initializePlugin`
succeeds and logs message 134 with the DN, the attribute and both
values.
- `testDuplicateFilterCriteriaAreAllEnforced`: a plugin loaded with both
values refuses an employee whose manager matches only
`(employeeType=manager)`, refuses one whose manager matches only
`(description=approved)`, and accepts one whose manager matches both.
The two "only one" steps make sure that neither filter alone is the one
enforced.
- `testDuplicateFilterCriteriaIsRejected`: on the running plugin, adding
`manager :(description=approved)` next to
`manager:(employeeType=manager)` is refused, and the reason names both
values.
- `testDuplicateFilterCriteriaCanBeDisabled`, and
`testCheckReferencesWithoutPreOperationTypesCanBeDisabled` for the #1118
configurations: a plugin loaded with the warning accepts its
configuration with `enabled: false`, and still refuses it with `enabled:
true`.
- `testFilterCriteriaForTwoAttributeTypesAreNotDuplicates`:
`manager:(…)` with `member:(…)` is acceptable, and a manager that
matches only the `manager` filter is accepted.

The #1158 case of `validConfigs` with a colon inside the filter now has
one value, `member:(&(o=urn:example)(cn:dn:=x))`, so that it stays a
clean load.

Without the fix (on #1167) the 10 cases of the first round fail and the
other 65 pass. With it the class passes 82/82. The 6 disable cases fail
with the first round's `isConfigurationChangeAcceptable`, and
`testFilterCriteriaForTwoAttributeTypesAreNotDuplicates` fails when
every value is grouped under the first attribute type, whether in the
duplicate check or in the filters that are enforced.

## Related

While writing the enforcement test I found that both `doPreOperation`
hooks stop after their first check, because a passing check's result
code is `null` rather than `SUCCESS`; that is why the test checks
`continueProcessing()`. Not changed here: tracked in #1173.