Admin users list usability, buttons to delete users

[HebaruSan]

Motivation

See #413; the admin user list has several annoying layout quirks and doesn't allow the main operation I want to do there: deleting spam users.

Changes

• Each column of the users table is now a static width, the contents do not overflow onto neighboring cells, and the email and forum cells may be hovered to view the full text in a tooltip
• The username cells now have Delete buttons that show a confirmation prompt when clicked, and if you confirm that you really want to delete, the user is deleted and the list is refreshed
  Note that since this is intended for nuisance users who aren't really users of the site, it does not do anything to clean up mods created by the user. It just deletes the user.
• The created column no longer displays seconds or milliseconds
• The public and admin columns are moved towards the left, after created, so the overall logic is basic info, contact info + socials, description
• The Twitter, Reddit, and IRC fields are combined into one "Socials" column, twice as wide as the username column, that shows them all plus KerbalX and GitHub, to make horizontal room for other fields
• The location column is removed completely because it is used nowhere and does nothing
• The description column is now twice the width of the socials column (4x the width of username), renders markdown with bleach, and has a vertical scrollbar if the total height is greater than 6em

Depends on #316
Fixes #413.

[DasSkelett]

Note that since this is intended for nuisance users who aren't really users of the site, it does not do anything to clean up mods created by the user. It just deletes the user.

Then we should make sure we do block the operation whenever there's any other object in the database that refers to this user (mod, mod list, mod pack, following).
We can't rely on the admin having checked all of them (may not even be possible) before pressing the button, and we would end up with objects that have a NULL user/user_id, which we probably don't handle correctly in a lot of places.

Setting all those user_id columns to non-nullable should make the database throw an error that we can catch, another option would be querying each of those tables for rows with a matching user id.

[HebaruSan]

I was hoping that we could finish up #316 and rely on the db to do that stuff for us, separate from the frontend-y stuff in this PR. Is that possible?

[DasSkelett]

Oh okay, I thought you wanted to merge this PR independently of/before #316, because it isn't mentioned anywhere in the description that it depends on it.
But yes, the db can handle most, except deleting files from disk, we'll have to do this ourselves in the backend code. If you want to stick to the /admin/delete_user/<int:user_id> route (instead of using the /api/ one from #316 as well), I should probably factor that code out into a separate function that we can call from this route as well.