Adding generic version entities for SFS API Responses

[arthuraraujo-msft]

Helps #50

For the same APIs, SFS will start sending different fields in the response. which may or not be present. While an offline discussion goes on about how the client should specify which entity it wants, we must be able to parse the different responses to be ready for the App version changes.

For example:

Generic Version Entity:

{
  "ContentId": {
    "Namespace": "default",
    "Name": "<name>",
    "Version": "<version>"
  }
}

App Version Entity:

{
  "ContentId": {
    "Namespace": "default",
    "Name": "<app name>",
    "Version": "<version>"
  },
  "UpdateId": "<id>",
  "Prerequisites": [
    {
      "Namespace": "default",
      "Name": "<prereq name>",
      "Version": "<version>"
    }
  ]
}

In order to avoid creating one implementation for each entity, I'm switching the 1:1 APIs to return more generic entities that can be mapped to a single entity. The API implementations won't be aware of the types, that will only be taken care of during parsing from the server, and during transformation in the final step.

For this PR I'm adding a Generic entity, which is the current response schema of SFS. The App version entity should be coming next.