[http-client-csharp] Do we still need `CSharpType`?

There once was a discussion around "source of truth" that we would like to decide which class should carry some property of a type, such as `Name`, `Namespace`, `GenericArguments`, etc.

In `autorest.csharp`, the `CSharpType` works as if it is a union type of `System.Type` and our `TypeProvider`, by calling `FrameworkType` or `Implementation` property, we could distinguish which variant this `CSharpType` comes from.

In our MTG here, `CSharpType` has been reduced to only carry the information that works as a "shell" of a type, such as name, namespace, generic arguments, declaring type, etc. And `TypeProvider` carries something more - including the implementations, because majority of the instance of `TypeProvider` are "emittable", we could write them onto the disk as a `cs` file, and we should.

But during the developing of our Azure Plugin and Azure Mgmt Plugin, we find that the boundary between them are blurry now.
Wei is working on a feature about `SystemObjectType`, which represents a `System.Type` from an existing library. This is useful in mgmt generator because in mgmt, we would like some particular models provided by the core azure libraries to be "replaced" by some classes defined in our mgmt core libraries `Azure.ResourceManager` to produce a more unified SDK library.
We could notice that this `SystemObjectType` also holds an instance of `System.Type` - then what if we use it to represent a string? It should be capable of.

Therefore I would like to propose that we should remove the class `CSharpType`, and wherever we used to use `CSharpType`, we could replace it with a specific `TypeProvider`.
For those previously are a `CSharpType` associated with a `System.Type`, we could have a `FrameworkTypeProvider` which produces you back the `System.Type` - and the writer should also work fine because the writer only cares the namespace, name, and generic arguments of the type, all these things are suitable for a `TypeProvider` to have.

Also this would make our "reference map" to be possible. Currently, all the signatures are using `CSharpType`, we could never know where this type comes from, therefore we could not build a reference map from our client types (root types). But if we use `TypeProvider` in those signatures, we should be able to build a reference type just using our `TypeProvider`s, and on this part, we do not have to rely on Roslyn any more.

To summarize, my proposal is that we could remove `CSharpType` and combine its functionality into `TypeProvider`, or a derived type of `TypeProvider` (for instance `FrameworkTypeProvider`).
This could be a big change, but I think this should be good to simplify our code base, and make it more reliable.