Add ESRB Rating Information

[tech1ndex]

• Adds new dataclass for ESRBRatings.
• Adds enum for ESRB Rating system to allow for consistent use throughout different classes.
• Adds helper classes for get_free_games to allow for additional enrichment of the free game data which is currently limited.
• Enriches this existing game data with ESRB rating and content descriptors, which allows for filtering based on them.
• Adds a new get_free_games_with_ratings method to the API that fetches ESRB ratings for free games and includes it in the response.
• Adds examples for updated usage.

[tech1ndex]

Hi,

So for the background:

I have been using this library in my project that notifies a Signal Group when games are marked free. Recently I had a Feature Request to add ESRB Rating info to the message which I think is valid however as I am using the get_free_games method, the path on the API that is currently being called there doesn't seem to support that. I think the easiest way to implement this while maintaining the existing patterns in this codebase would simply to be adding a supplementary _with_ratings method along with some helper methods to keep everything as DRY and single responsibility as possible.

I was also thinking of adding some validators for all of the data we are parsing now but I wanted to keep the scope as limited as possible for this PR. Can plan for a subsequent change if this is approved.

Please take a look and I am happy to discuss further. Thanks!

[tech1ndex]

Hey @SD4RK / @woctezuma ,

Would I be able to get some feedback here?

[SD4RK]

Hello, sorry for the delay, was busy with some irl stuff.

I think the feature itself is fine, but the amount of parsing and handling is a little bit too much in my opinion. Library was made with as less parsing and validation in mind as possible, to just leave users with pretty much raw API (as this API is not stable and is not meant to be used outside of the store app itself, and by any means and can be changed at any time, I don't see much reason in this).
The enums and some validation that I had was for the simple reason of convinience - because those hardcoded IDs are not really findable without looking through the store traffic, and I wanted it to be a package that you can use without doing the research for it. And validation is simply there so you can see the errors better and use your default try-except workflow instead of parsing JSON yourself each time. So enums I think are fine, but extra preprocessing of the data is not something that I think is much needed.