Allow enums in `@visibility` decorator

[timotheeguerin]

Playground Link

Things to think about:

• what to we do with existing string value(deprecate?)
• change the api to use union? @visibility(HttpVis.read | HttpVis.write)
• multiple @visibility does it append or override: We definitly need some appending functionality so you can provide visibiity foir different protocol but not being able to override might be limiting.

[qiaozha]

Not sure if we can use this issue to share all the visbility related feature requirements, here's some requirements from previous discussion.

• visibility should use an enumerated type rather than a string (for both model and operation visibility decorators @visibility @parameterVisibility @returnTypeVisibility @withVisibility @withDefaultKeyVisibility including the future planning of visibility and optionality combination https://github.com/Azure/typespec-azure/issues/1117 [in fact, everywhere that visibility is used])

• TypeSpec should provide helpers to transform visibility into the information that emitters need when they are creating client models and serializing and deserializing operation requests and responses

• Provide a mechanism for specifying the names of models transformed by visibility Proposal: to extend the @clientName decorator to support Visibility rename

  @@clientName(ModelVisibility, "typescript", "ModelVisibilityCreateParameters", HttpVis.Create | HttpVis.Update)

Here's a unresolved topic from dotnet and java codegen side, which I haven't thought of a better proposal for it.

• How to avoid cascade splitting models In the case that when one model has a deep nested model layers, it doesn't quite make sense if we just add visibility for one properties in a small properties. however we have to split all the models involved to the request body. see the playground link ( we can comment out the line 10 for visibility change to see the change.)