UserController used to bind request params directly to the User
domain, which would allow Grails' data binding rules, not our policy,
to determine which roles could be assigned.

Extract role IDs at the controller and pass them to the service as
explicit arguments; make the service reject any role-shaped keys still
in the params map (`rejectRoleKeysInParams()`) so the boundary
is enforced from both sides. A `popRoleParamsBeforeBinding()` helper
applies the same extraction pattern consistently in `save()` and
`update()`.

Consolidate the permission checks themselves into
`checkCanAddOrRemoveRoles()` and `checkCanAddOrRemoveLocationRoles()`,
used by every path that can change role assignments: `saveUser`,
`updateUser`, `saveLocationRole`, `deleteLocationRole`.

Role validation logic moves into `validateAndApplyRoleChanges()` and
`validateAndApplyLocationRoleChanges()`, which add and remove roles
one at a time to steer clear of any GORM/Hibernate cascade quirks.

`checkCanAddOrRemove*Roles()` takes the target `User` as a parameter so
validation errors attach to the right object. A new `rejectRoleChange`
helper throws `ValidationException` with a localized message that
UserController surfaces directly in `flash.message` instead of
re-localizing.

Separately, `user.edit` and `user.show` had no entry in any of
`RoleInterceptor`'s role lists. Any authenticated, browse-capable
user could reach them through the default fall-through path. Add
them to `managerActions` so the interceptor enforces at least
manager-level access for both. This gets exercise in a big Spock
table in `RoleInterceptorSpec`.

While I was in there:
- Hoisted `deleteLocationRole` logic from `UserController` into
  `UserService`.
- Added five message keys to clarify error conditions to users.
- Added Javadoc on `saveUser`, `updateUser`, and `rejectRoleKeysInParams()`
  to explain why role IDs must not travel inside the params map.
- Covered the controller/service boundary with a new
  `UserServiceRoleValidationSpec` exercising role assignment, role
  removal, and params-map rejection.
- Updated `UserControllerSpec` setup to stub `session.user`, since
  `saveUser`'s new signature reads `session.user.id` to identify the
  requesting user.
- Used idiomatic Spock in `RoleInterceptorSpec`: `@Unroll` hoisted
  to the class, `||` separator marking expected output, `assert` used
  in expectations that delegate via a helper method.

Signed-off-by: Matthew Pearson <[email protected]>

Remove unused `user.errors.locationRolesNotAllowedOnCreate.message`.

Remove unused `LocationRoleDataService.deleteLocationRole` helper
(plus the now-orphaned import and field in `UserController`).

Throw `ValidationException` rather than `IllegalArgumentException`
from `saveUser` and `rejectRoleKeysInParams` so `UserController`'s
existing catch produces a sensible error view.

`UserService.deleteLocationRole` now takes a `LocationRole` entity
instead of an id, so the controller's existing lookup isn't repeated
inside the service.

Update `UserServiceRoleValidationSpec` to match.

Signed-off-by: Matthew Pearson <[email protected]>