Introduce a flag to disable client hierarchy in tcgc

[tadelesh]

In this PR, I changed the default client hierarchy behavior for service not using @client and @operationGroup. Current default behavior and customization logic could refer doc. The original design will introduce a breaking change for existed branded services' client generation if they have sub namespace or interface in their tsp definitions. At that time, we went through all the existed branded services and added customization for them. But after the new version released, we received some service feedbacks such breaking changes impact their ongoing works (client structures are different, we told them to remove interface or use client.tsp to redefine the structure). Also, JS RLC always needs flattened result. This made me think of introducing a flag to control if we should regard tsp's namespace and interface as client hierarchy. Any thoughts?

@Azure/dpg-devs @Azure/dpg-owners

[qiaozha]

I think we need to figure out what to do if:

1. hierarchy is disabled and @operationGroup decorator is present ?
2. hierarchy is enabled and @operationGroup is present ? Is it correct to return the @operationGroup defined hierarchy layers instead of the original hierarchy layers ?

If we agree to deprecate @operationGroup decorator, I think have a flag to disable hierarchy makes sense, and if customers want hierarchy they could define it with interfaces hierarchies.