Add option to restrict a user to a group instead of banning them

[bonelifer]

Answers CDB topic 240381, which asked whether Ban Hammer could move a user into a heavily-limited group for a set time instead of banning them outright.

What this adds:

• A new "Restrict this user" option on the member profile page, next to the existing Ban Hammer options, shown only when a restrict-group is configured in the ACP and the viewer has m_ban.
• A moderator picks a duration (or permanent), confirms, and the user is moved into the configured group as their new default group — they keep the ability to log in, with whatever permissions that group has.
• A new cron task (restriction_expiry) checks periodically for expired restrictions and automatically restores the user's original group.
• A new ACP setting, "Restrict to group," mirroring the existing "Move to group" field. Leaving it unset (the default) keeps this feature off entirely — nothing changes for boards that don't configure it.

New table: banhammer_restrict, tracking user_id, original_group_id, and restrict_until so the cron task knows what to restore and when.

cc @kaileymsnay

[bonelifer]

(Claude, replying on William's behalf)

This branch needed a rebase onto current master (it was 13 commits behind) to resolve merge conflicts in config/services.yml and event/banhammer_listener.php, both caused by #25 (merged) adding new content in the same spots this PR does. Resolved by keeping both sides' additions - the ban_domain and restriction_expiry service blocks together, and core.mcp_queue_approve_details_template added alongside this PR's core.memberlist_view_profile change.

While validating the rebased content, found and fixed three real bugs, in a follow-up commit:

• Duration math: restrict_until was computed as time() + (restrict_time * 86400), treating restrict_time as days. It's actually minutes (ban_length_options()'s keys, same unit user_ban() uses elsewhere in this file) - every duration was off by a factor of 1440x, and the "1 year" option risked overflowing the column entirely. Fixed the multiplier to 60.
• Panel-toggle JS bug: the new "Restrict this user" trigger reuses the .bh-click class, but the existing click handler hardcoded #bh-options as the panel to toggle - clicking it opened/closed the unrelated Ban Hammer panel instead of its own. Changed it to toggle the clicked trigger's own next .inner sibling instead.
• Stale file headers on the two new files (cron/task/restriction_expiry.php, migrations/restrict_group.php) - updated to match the header standardized across the rest of the repo.

Also added a check do_restrict_stuff() was missing: it didn't skip already-banned users the way do_ban_hammer_stuff() does, so it was offering to "restrict" someone who can't log in at all regardless of group.

PR is clean/mergeable against current master now.

[bonelifer]

(Claude, replying on William's behalf)

One more rebase — merging #33 just now reintroduced a conflict in controller/admin_controller.php (both PRs add a new field to the same $this->template->assign_vars() array). Resolved by keeping both: RESTRICT_GROUP alongside the already-merged SFS_ALLOW_HTTP/SFS_API_KEY/SFS_CURL. No functional change beyond that.

Clean/mergeable against current master again.