Add new classes for Tarallo v2

[e-caste]

@lvps you can surely provide some details about how you think it should be implemented

[lvps]

We need different classes:

• Item (received from the server)
  • code: str is mandatory
  • features: dict is mandatory (can be empty)
  • product: Product is optional
  • location: list is mandatory (can be empty), it's the full item path
  • contents: list is optional, it's a list of other Item
• ItemToUpload (new item that doesn't exist on the server)
  • code: str is optional
  • features: dict is mandatory (can be empty)
  • parent: str is optional (it's the container, without full path)
  • contents: list is optional, it's a list of other ItemToUpload
  • Brand, model and variant are features, do not send a full product here
• Product
  • brand: str is mandatory
  • model: str is mandatory
  • variant: str is mandatory (but you can hide it in the GUI if it is the literally default with case sensitive comparison)
  • features: dict is mandatory (can be empty)
• ProductToUpload
  • features: dict is mandatory (can be empty)
  • Brand, model and variant are part of the API URL

If done like this, they can be serialized/unserialized in JSON trivially.

Then current pytarallo methods need to be updated:

• Methods that get things from the server should return Item or Product o lists of them or dicts of them or anything that makes sense
• Methods that upload things to the tarallo should expect ItemToUpload or ProductToUpload as parameters
• Methods that update features can take in a dict of changed features (se to NULL to delete them from tarallo), how you get that from these classes is an implementation detail (and I also don't remember what we're doing now, but probably we can reuse that without any significant changes)
• In no case an Item shall contain an ItemToUpload or a ProductToUpload, and other combinations of ToUpload and not to upload.

Methods that do other kind of queries (from a feature value get a list of codes, etc...) don't need to be changed, as they will still require strings and return lists of strings or whatever they are doing now

For Item and Product, you will receive a JSON from the tarallo that has the same structure, it's up to you how to parse and unserialize it. In the tarallo we have to do the reverse, but there is no magic: we simply walk through the resulting "dict" (an array in PHP) and add every bit of information to our objects.

For ItemToUpload and ProductToUpload, users of pytarallo (developers) will need some methods to set features (a .setFeature(name, value) is really helpful), code, etc... and then you serialize everything and send it to APIs

Rationale: these differences (Item vs ItemToUpload, Product vs ProductToUpload) are intrinsically part of the process and everything, and we've noticed that people often got confused by having a single Item class where sometimes they have a path for a location, sometimes just the parent items, and so on.

If you really want we can ignore the brand, model and variant strings for product uploads, so Product and ProductToUpload are the same and you can just create a single Product class, but this will probably end up confusing for developerz again.

[e-caste]

@pippo314 the reference for the current version of the APIs can be found at https://github.com/weee-open/tarallo/wiki