Various grief report fixes

[Toastbrot236]

This PR fixes multiple issues that were left in the grief report reimplementation from forever ago. Most notably, it does these changes:

• The names of all classes related to grief reports now finally follow our usual naming rules. Classes related to report request XML are now prefixed with Serialized and ones related to internal/DB stuff are prefixed with Game now.
• The Reports table was renamed to GameGriefReports for consistency
• The ReportPlayersRelations table was renamed to ReportPlayerRelations to fix the annoying typo
• ReportPlayerRelation.Timestamp was removed since it wasn't set or used anywhere (meaning all rows had it set to -infinity), and the game doesn't actually send any player-specific timestamps, so this column was also pointless. The report's own upload date is enough.
• ReportPlayerRelation.UserId is now nullable to allow the server to store report players who don't have a corresponding GameUser entity on the server. This can likely happen if the report includes players from another server, and idk whether reports also include local guests or not.
• Due to the above, ReportPlayerRelation.UserId is no longer part of its primary key, instead it now consists of ReportId and PlayerNumber, similarly to how it's now done in GamePhotoSubject. Since we can't rely on the game to send unique player numbers (due to potentially bugged or forged requests), the player number sent by the game is no longer directly saved to DB. Instead, we use it to order the player list, and then we create our own unique player numbers.
• ReportPlayerRelation now stores the username originally included in the request, so we could identify players incase their UserIds are null (similarly to how we also store the username separately in GamePhotoSubjects)
• All DB methods related to grief reports now compare referenced entities (levels, users) by foreign key instead of object reference, for the same reason as in Update all DB methods to always compare referenced entities by FK #1153

This needs a few unit tests, and the DB migrations also have to be tested (I have tested some of the SQL statements in the Up() methods separately, but the migrations should still be tested in their entirety).