Check Python client code base on using PLFM object model

Checking the code and found questionable constructors for:

• PartialRowset – http://hud.rel.rest.doc.sagebase.org.s3-website-us-east-1.amazonaws.com/org/sagebionetworks/repo/model/table/PartialRowSet.html

• PartialRow – http://hud.rel.rest.doc.sagebase.org.s3-website-us-east-1.amazonaws.com/org/sagebionetworks/repo/model/table/PartialRow.html

• Row – http://hud.rel.rest.doc.sagebase.org.s3-website-us-east-1.amazonaws.com/org/sagebionetworks/repo/model/table/Row.html

• SelectColumn – http://hud.rel.rest.doc.sagebase.org.s3-website-us-east-1.amazonaws.com/org/sagebionetworks/repo/model/table/SelectColumn.html

Though PartialRowSet and PartialRow constructor already diverted from theirs backend schema.

Notes: looking into every class implementation I found that only Activity implemented the idea that the constructor takes a dict object and initialize the object using the dict data, while other class implemented **kwagrs.

Notes to self: https://softwareengineering.stackexchange.com/questions/294320/is-kwargs-an-antipattern

Discussed with Ziming about classes mentioned above:

• PartialRowSet & PartialRow are constructors for the client users to use. We do not read data from the backend into these constructors.

• Row is used to read backend data:

This indicates that the problem is in how we handle the dict object we get back from a http call rather than the constructor itself. Will look into all places we use **.

I found many places where we used this pattern:
return [UserGroupHeader(**result) for result in self._GET_paginated(uri)]
However, all constructors that was used already accept **kwargs, so we should not have any problem there. The only places that need to be fixed are the places we used Row and SelectColumn with this pattern. I will fix these places.

https://github.com/Sage-Bionetworks/synapsePythonClient/pull/577