Reduce Number of Methods Generates in Clients

[alzimmermsft]

Currently, depending on the configuration setup, in ClientMethodMapper we can end up generating overloads of methods that'll never be used. For example, if Context is enabled we'll end up with api(params) and api(paramsPlusContext) and if this is being used with a hand-written SDK the non-Context overload will almost never be called as the written layer will handle either propagating a Context or use an empty Context. This has a few downsides, it increases the size of JARs, results in longer compilation times, and skews test code coverage, given that we should look into the following ideas/improvements:

• Only generate a Context overload if the generated client will be in implementation. The service client being in implementation is a good indicator on whether the generated code is being used in a hand-written SDK.
• Only generate Response-based APIs if the generated client will be in implementation. The hand-written layer can handle cracking open the Response to return T.

[weidongxu-microsoft]

If the client is generated only for implementation, one might actually use the sync-methods=NONE in readme (that seems to be the original intention) to only generate the Response Rest methods (that likely be the minimum), and wrapper client can do whatever they want?