use clientConfig struct for unmarshalling yarpc clients instead of generic classConfig

[rpatali]

• There are additional configurations such as exposed methods, sidecar router, etc. that need to be configured in the Gateway and the generic ClassConfig doesn't provide a strict contract for those to be present.
• Using ClientConfig makes the implementation for the various Clients consistent in implementation.
• ClientConfig always assumes thriftFile whereas YARPC clients use protoFiles, migrating clientConfig to a IDL agnostic idlFile naming

This is a breaking change for existing users of Zanzibar due to the name change and probably requires a version bump.

The scope of this diff is to only handle the client-side changes to unify Thrift vs. Proto struct to unblock other development that depends on this struct. Will be following up with a thorough cleanup of thriftFile -> idlFile for the endpoint as well as all other references and implement non-nil SpecGenerator impl for YARPC Client.

[coveralls]

Coverage increased (+0.2%) to 67.849% when pulling 231e6b2 on rpatali/yarpcClientConfig into e6898db on master.