Add bulk delete for questions, answers and users (spam attack cleanup) #1601

Is your feature request related to a problem? Please describe

When an Answer site gets hit by a spam wave — bot accounts registering and flooding the site with spam questions/answers — cleaning up afterwards is almost entirely manual. Today, moderators have to:

• delete every spam question/answer one by one in Admin → Questions / Answers;
• handle flagged spam item by item in the Review queue;
• delete each spam account one by one in Admin → Users (the existing "delete user and remove all their content" option helps, but it still has to be repeated for every single account).

The only bulk operations that currently exist are bulk adding users (AddUsersReq), and the DELETE /answer/admin/api/delete/permanently endpoint, which only purges already-deleted users/questions/answers and offers no selection or filtering — so it can't be used to remove live spam either.

After a real spam attack this easily adds up to hundreds of individual clicks or single-item API calls before the site looks clean again.

Describe the solution you'd like

Bulk delete support in the admin console (and the admin API) for all three object types:

1. Questions / answers: multi-select checkboxes in the admin question/answer lists, with a "Delete" bulk action.
2. Users: multi-select in the admin user list with a bulk delete action, reusing the existing remove_all_content option so the selected users and all their posts can be removed in one go.
3. (Nice to have) Filter-based bulk delete tailored to spam waves, e.g. "delete all content authored by user X" or "delete all users registered in a given time window with ≤ N posts", ideally with a preview and confirmation of what will be removed.
4. Matching admin API endpoints that accept a list of IDs, so large cleanups can be scripted instead of clicked.

Describe alternatives you've considered

• Deleting one by one (current behavior): fine for isolated cases, unmanageable during a spam wave.
• Direct database cleanup: risky — it bypasses all business logic (counts, rank/reputation updates, search indexing, notifications) and isn't realistic for most site admins.
• Scripting the existing single-item admin APIs in a loop: technically possible today, but slow, fragile in the face of partial failures, and out of reach for admins without programming skills.