Disambiguate twin classes from hub and dps service clients

[drwill-ms]

Especially for customers that use our SDK clients together in the same file, we prefer to avoid naming conflicts that they otherwise have to disambiguate by using the full namespace (or aliasing types).

For this reason, I've renamed most twin types in hub service client to be ClientTwin* and in dps service client to be ProvisioningTwin*.

I also took a look at the other type names and resolved some wrongness (like DeviceStatus when it also applies to modules, so renamed to ClientStatus).

The other change was TwinCollection and TwinProperties. I spent more time on this than anything. The user doesn't really interact with the TwinCollection type except off of the Twin class. It contains the Desired and Reported properties. So, I renamed that to ClientTwinDocument, which isn't a great name but not one the user should ever use directly. That freed up the TwinProperties name for what was TwinCollection, so it is now ClientTwinProperties. The other related types followed suit, so ClientTwinPropertyValue and ClientTwinPropertyArray.

Finally, the hub device client has some small number of classes for twin. I renamed it from ClientTwin to just Twin.

Thoughts?

[patilsnr]

Optimistic sign off

[drwill-ms]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).