Expose public setter of namespace

[live1206]

After the tsp namespace feature implementation in #5443, the namespace of model, enum and modelFactory have been changed from previous XXX.Models to XXX.
For Azure plugin, we would like the namespace for model and enum to be XXX.Models.

• Expose public setter of namespace, use visitor to update namespace of TypeProvider in Azure plugin. https://github.com/Azure/azure-sdk-for-net/pull/48197/files#diff-a6219e0492ffcf33fd4bb03be26f1e6bc04a84ee1e2723b4d58d5adbcdb031ef
• Expose provider types to let sub-plugin identify.
• Remove duplicated instance of ModelFactoryProvider
• Remove Namespace property from CSharp

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

Microsoft.Generator.CSharp

[ArcturusZhang]

LGTM.
In the meantime, since we have more and more callbacks on the typefactory, it occurs to me that do we need to consider to categorize these methods into different classes?
For instance, for these namespace related ones, maybe we could have something like

public class TypeFactory
{
public virtual NamespaceNamingStrategy NamespaceNamingStrategy {get;} = NamespaceNamingStrategy.Default;
}

and these methods could go to the NamespaceNamingStrategy class where could also hold those GetCleanNamespace methods.

[JoshLove-msft]

There's no need to use Lazy here. We can just cache the value in private field.

[live1206]

@JoshLove-msft
If you are saying like

internal ModelFactoryProvider ModelFactory { get; } = new ModelFactoryProvider(CodeModelPlugin.Instance.InputLibrary.InputNamespace.Models);

This will not work, because the field will be initialized while creating OutputLibrary instance, and it need CodeModelPlugin.Instance to be created. But CodeModelPlugin.Instance depends on the instance of OutputLibrary, we have a circular dependency here.

If you are saying like

internal ModelFactoryProvider ModelFactory { get; } = _field ??= new ModelFactoryProvider(CodeModelPlugin.Instance.InputLibrary.InputNamespace.Models);

why is this better than using Lazy?

[JoshLove-msft]

I'm suggesting that we use a private field to cache the value in the getter rather than using Lazy. Lazy is useful when there are concurrency concerns to ensure that the value is initialized only once. We don't have such concerns here, and there is a performance penalty to using Lazy.

[live1206]

Thought it's a good thing to be thread-safe ready. But if that's not what we need for now, sure.