[#250] Reject invalid temporal constraint durations and tolerate stored ones

[vharseko]

Fixes #250

Problem

effectiveRoles is a virtual property returned by default, so its onRetrieve script runs on every read and every update of a user. The script parses each temporal constraint duration with Joda's Interval.parse, which throws on an interval whose end is before its start. Nothing validated the duration when a grant or a role was written, so once such a value was stored the user could neither be read nor fixed through managed/user (500 effectiveRoles onRetrieve script encountered exception).

The admin UI produced such a value itself: with a start date in the future and an empty end date, convertToIntervalString sent the current time as the end. Replaying that exact request on a build without the fix: POST managed/role/<id>/members returns 500 after the grant is already stored, and from then on GET managed/user/<id> and even the user's grant list return 500.

Changes

Reject on write (400 instead of storing the value)

• DateUtil.isValidInterval(String): true only if Interval.parse accepts the string (null, garbage and reversed intervals are invalid; datetime/period forms stay valid).
• RelationshipValidator.validateTemporalConstraints: grant constraints must be an array of at most one constraint with a valid duration. Called from validateRelationship (before the managed object is written and before virtual properties are computed) and from RelationshipProvider.convertToRepoObject (direct writes to a relationship endpoint), replacing the existing "Only 1 temporal constraint" check there.
• conditionalRoles.roleCreate/roleUpdate: the same check for a role's own temporal constraints.

Tolerate values that are already stored

• effectiveRoles.processConstraints and temporalConstraints.areConstraintsExpired skip an invalid constraint with a warning; it never grants the role.
• postOperation-roles.createJobsForConstraint logs and creates no schedules for an invalid duration instead of failing a request whose resource is already stored.

Admin UI

• TemporalConstraintsUtils.isValidInterval requires both dates and the end after the start; TemporalConstraintsFormView shows an error under the end date, and EditRoleView (Save) and MembersDialog (Add) stay disabled while the form is invalid. EditRoleView.save also refuses to send an invalid form.

Testing

• DateUtilTest, RelationshipValidatorTest (valid / invalid _refProperties), all openidm-core tests.
• JS: effectiveRolesTest, temporalConstraintsTest, conditionalRolesTest cover reversed and unparseable durations; without the effectiveRoles.js change the new test fails with the exception from the issue. testRunner.js now provides a no-op logger, as the scripts log through the binding OpenIDM supplies at runtime.
• QUnit: isValidInterval (125 tests, 0 failed); eslint clean on the changed UI files.
• Manually in the admin UI on a build from this branch: role temporal constraint and "Add Role Members" with an empty end date show the error and keep Save / Add disabled; with a valid end date the role is saved (200) and the member is added (201). Over REST a reversed interval on a grant or a role is rejected with 400.