Add TypeReference.createInstance(Class<T>)

[alzimmermsft]

This PR adds the method <T> TypeReference<T> createInstance(Class<T>) to TypeReference. It allows for the creation and caching of non-parameterized TypeReferences.

[sima-zhu]

It looks a little weird by having both createInstance and public constructor.

[alzimmermsft]

They serve different purposes. The public constructor is for anonymous instances that use parameterized types for their T, such as Map<String, String>. This factory method is meant for non-parameterized Class types that can be safely cached and maintain T.

[srnagar]

Yeah, this is a bit odd. They serve different purposes but the constructor works for all cases and if the caller always uses the ctor not knowing about the static createInstance method, it may defeat the purpose of caching.
Also, in azure-core, there is a TypeUtil that has a utility method to createParameterizedType() that may be useful.

[sima-zhu]

The public constructor work with most of the cases like (concrete class, paramterized type), but not the clazz variable cases.
E.g.

public void someMethod(Class<T> clazz) {
    TypeReference<T> type = new TypeReference<T>() {} // type is null in this case, no matter what clazz you passed in.
    ...
 }

In this case, we must use the createInstance API. However, createInstance API does not serve all purpose as well, we cannot pass the parameterized type here.

So both APIs have hard limitations and caching strategy are different behind the API. If I am not expert users I would confuse of the usage here.

[alzimmermsft]

Agreed @sima-zhu, having both does lead to some confusion. Luckily, this type is mainly going to be used internally where determining whether to use createInstance(Class<T>) or the constructor will be based on the API. If the type is known ahead of time and it is parameterized the only choice is to use the constructor, if the type is known but is a Class<T> or is passed into the API createInstance(Class<T>) will be used.