Test ARM, test case for location-based resource

[v-hongli1]

• ARM, test case for location-based resource #686

Cadl Ranch Contribution Checklist:

• I have written a scenario spec
• I have meaningful @scenario names. Someone can look at the list of scenarios and understand what I'm covering.
• I have written a mock API
• I have used @scenarioDocs for extra scenario description and to tell people how to pass my mock api check.

[tadelesh]

overall lgtm. @XiaofeiCao please help to ensure the mock api is right before merge.

[XiaofeiCao]

I prefer to call this scenario Azure_ResourceManager_Models_Resources_Location_ResourceGroup_createOrUpdate
or
Azure_ResourceManager_Models_Resources_Location_ResourceGroupLocationResource_createOrUpdate,
since this PR covers ResourceGroupLocationResource, and we also have SubscriptionLocationResource and TenantLocationResource which we don't cover here.
@weidongxu-microsoft @tadelesh Would like your opinion.

[tadelesh]

i prefer the shorter one.

[XiaofeiCao]

@iscai-msft Here's another case where we may need @clientName:
We want the scenario name be Azure_ResourceManager_Models_Resources_Location_ResourceGroup_createOrUpdate, this may require an interface called ResourceGroup.
For generated SDK, it'll generate a client called ResourceGroup... This is not a big issue since it resides under the corresponding namespace, though still a bit weird to me...

[iscai-msft]

@XiaofeiCao is it possible for you to compile a list of all of the categories and subcategories, so we can agree on the current ordering? Everything's getting long and confusing imo. Something like

Azure
 |-> ResourceManager
       |-> Models
             |-> Resources
       | -> CommonTypes 

For example, I don't think we need Models as a namespace

[XiaofeiCao]

@iscai-msft Here's what's intended to be:

Azure
 |-> ResourceManager
       |-> Models
             |-> Resources // resources and their common CRUD operations
             |-> CommonTypes // special common-types like ManagedIdentity
                |-> ManagedIdentities
                |-> EncryptionProperties
                |-> SKUs, etc
       |-> Operations // uncommon operations, or operations with multiple scenarios, irrelavant of resource types
             |-> LROs(including pageable LROs)
             |-> Resource Actions //import, export, upload, trigger, etc
             |-> Resource Move // move resource to another subscription(not sure, maybe just in Resources is enough?)

Basically it's following this issue's structure, and typespec-azure's sample folder. Any suggestions are welcome too!

Models seems unnecessary, we could remove that.

[iscai-msft]

Here is my suggestion, @timotheeguerin please lmk your thoughts

Azure
 |-> ResourceManager
       |-> Resources // resources and their common CRUD operations
             |-> Actions
             |-> Move (?)
       |-> CommonTypes // special common-types like ManagedIdentity
          |-> ManagedIdentities
          |-> EncryptionProperties
          |-> SKUs, etc
       |-> Operations
             |-> LROs(including pageable LROs)

[v-hongli1]

The previously referenced ARM Resourcec type @parentResource did not match the description in https://azure.github.io/typespec-azure/docs/howtos/ARM/resource-type#location-based-resource, so it was fixed by commit 0c483cf