Improve logging robustness

[jakevoytko]

Right now, the logs are basically targeted at development, and it's assumed that failures in production will happen infrequently enough that it's reasonable to look through the systemd logs to debug production problems. For instance, this is how I investigated problems with discordgo freezing during Discord downtime in April.

Right now the situation is mixed.. it logs mostly where it should, but I wasn't principled about severity. So...

• Rethink when errors are info logged, and when they are fatal
• Add a better panic util (as opposed to errors.New('wat'))
• Write logs to files as opposed to stdin/stdout
• Look into log rotation

[jakevoytko]

I've had some rethinking about this in light of my success in using journalctl for basic log management. I think that some of the requirements can be dropped (writing logs to files), but I should still go through and audit when errors are fatal and when they are just verbose

A separate task would also involve going through and adding Prometheus metrics, but I don't think the metrics would be very interesting right now, so I'm going to just leave that for when it's a pain point