Refactoring of Game and dlc info and Api methods

[GB609]

This is something we should maybe tackle after release 1.4.0.

The data structure in Game is a very confusing mixture of simple json dicts and class properties.
A lof ot the API methods which are used to extract info from Game instances take optional parameters related to DLC, like dlc_title or dlc_name. These are used in ifs within the methods and sometimes completely change the behavior.

The same applies to methods related to download and install in LibraryEntry.

installer.py on the contrary only knows Game instance. So any extra info required to install a dlc would also have to be passed in explicitly.

I'd like to change that by using a more object-oriented approach:

class GogItem:
    """Represents the basic contract/properties any installable item like Game or DLC needs:
    - id
    - title
    - installers
    - install directory
    - ... (some more i can't see right now)
    """

class Game(GogItem):
    """most of what was in here before will go to GogItem.
    Some methods which are currently using some if on dlc properties will be split up"""

class DLC(GogItem):
    """Basic idea: Will be constructed from within Game and holds a reference to its parent Game.
    This allows to define some getter properties that just redirect to the Game, e.g. for the install_dir"""

Most methods which currently take a mix of Game and dlc-related simple types could be refactored to utilize GogItem instead.

Advantages:

• Leveraging that properly will reduce the number of individual parameters that have to be passed around in LibraryEntry and installer.py.
• This encapsulation also is more future proof-and allows for easy extension without bloating up method parameters everywhere.
• Some of the methods scattered around various files might be moved and concentrated in Game or DLC.
• direct usage of various dict keys from the api jsons are littered across the code everywhere. This duplication of code will lead to a lot of breaking code if gog ever changes just one key in that structural hierarchy. Using types properly will encapsulate that and make it much easier to maintain.
• IDEs cant help with hard coded strings for dict access. But they can help with methods, getters and class properties.
• it also means we can pull logic out of LibraryEntry