Refactor categories to extend GameCategory

[Toastbrot236]

This is a refactor which removes GameLevelCategory, GameUserCategory, their equivalent game and API serialization classes and makes all category classes directly extend GameCategory. De-duplicating category code, especially for the API responses, was suggested in a previous PR's review, and this is the easiest and least hacky way I could think of.

While I have tried to implement the suggested strategy of using a generic type for ApiCategoryResponse, it became too complicated for me due to one of the two FromOldList methods needing to call the Fetch method of every category in order to add their preview items to the responses. I've thought to instead have the preview item attribute be of type IApiResultResponse which both ApiGameLevelResponse and ApiGameUserResponse implement.

For LBP3 the Results attribute, which used to be in SerializedLevelCategory and SerializedUserCategory, is now in SerializedCategory and of type SerializedCategoryResultsList so the categories could include either users or levels as previews. This works with LBP3.

The overridden GameCategory.Fetch method now returns a DatabaseResultList, which references a nullable DatabaseList of GameLevels, GameUsers and GamePlaylists each (3 lists in total). This is so that both level and user categories could override the method without any problems, while also being a preparation to make searching users for LBP1-3 and the API (and then maybe also playlists in LBP1/3/API) alongside levels possible.

[Toastbrot236]

I don't really see anything wrong here, but since this is a relatively large refactor, I'll keep it unmerged for now incase anyone does want to review it.