Refactor RCheevosAchievementListForm and RCheevosLeaderboardListForm to not use a separate form for each respective item

[CasualPokePlayer]

These forms currently are just wrappers against FlowLayoutPanels that take in an array of RCheevosAchievementForm's/RCheevosLeaderboardForm's. This is grossly inefficient and can crash due to window handle exhaustion, and as such they're currently disabled (see #4478). They need to be refactored to not taken in a list of forms which all each end up creating a window handle.

[YoshiRulz]

I didn't even know you could put a Form in a controls collection. I guess it makes sense since it's a subclass of Control.

Is

-public partial class RCheevosAchievementForm : Form
+public partial class RCheevosAchievementForm : UserControl

sufficient?

[CasualPokePlayer]

Is

-public partial class RCheevosAchievementForm : Form
+public partial class RCheevosAchievementForm : UserControl

sufficient?

This doesn't seem to be sufficient, this rather just makes it so window handle creation for each control is deferred until showing the list form (which proceeds to crash if there's too many controls).

[CasualPokePlayer]

Note that it's not just the window handle of the RCheevosAchievementForm itself being a problem, but also all its components (Label/TextBox/CheckBox/PictureBox) which also each create a window handle, resulting in 14 window handles per achievement (1000 window handles would be fine technically, but not 14000).

[YoshiRulz]

Is this limit per window or per process? Could you, say, .Take(1000) and be sure it would never hit the limit? That would be much better than disabling the feature outright.

[CasualPokePlayer]

The limit is per process.

I wouldn't want to just arbitrary take some amount of achievements are there's handling to re-order achievements listed based on levels of importance (see OrderByKey).