fix, mgmt shadow properties from Resource/ProxyResource

[XiaofeiCao]

The shadow property is in the middle of the inheritance hierarchy. In this case, "ResourceWithWritableName", since it has parent class ProxyResource.

Previously, we only check if property is shadowed in the leaf subclass.
Now, we check if property is shadowed in the inheritance hierarchy, and use the one that's closest to the leaf.

code: 9149f75

generated code diffs are reordering of the shadowed properties(a side effect of the fix logic). Now properties from subclass will come before the ones from parent class.

"ResourceWithWritableName": {
  "description": "ARM resource.",
  "type": "object",
  "properties": {
    "id": {
      "description": "Resource ID.",
      "type": "string",
      "readOnly": true
    },
    "name": {
      "description": "Resource name.",
      "type": "string"
    },
    "type": {
      "description": "Resource type.",
      "type": "string",
      "readOnly": true
    }
  },
  "x-ms-azure-resource": true
},
"ProxyResourceWithWritableName": {
  "description": "ARM proxy resource.",
  "type": "object",
  "allOf": [
    {
      "$ref": "#/definitions/ResourceWithWritableName"
    }
  ],
  "properties": {}
},
"FirewallRule": {
  "description": "A server firewall rule.",
  "type": "object",
  "allOf": [
    {
      "$ref": "#/definitions/ProxyResourceWithWritableName"
    }
  ],
  "properties": {
    "properties": {
      "$ref": "#/definitions/ServerFirewallRuleProperties",
      "description": "Resource properties.",
      "x-ms-client-flatten": true
    }
  }
}

[weidongxu-microsoft]

What would happen of the class, if we did not have this fix?

[XiaofeiCao]

diff after fix here: Azure/azure-sdk-for-java@806b4e0#diff-a6e36e0731c287838e46e86be1e06840866bec2766bbe888a0de3deac129ee80

1. name will be improperly shadowed in FirewallRuleInner, also getter improperly generated for it.
   This is due to in current getFieldPropeties, we use name from ProxyResource, not the shadowed one in ResourceWithWritableName. Now we start search from subclass to parent, to choose the one closest to the leaf subclass.
   codegen fix here.
2. setter won't be generated for the writable name.
   Cause is the same.
3. fromJson would set name twice, once for name from ProxyResource, once for name from ResourceWithWritableName.
   codegen fix here

This is a special case for mgmt, as we have our own Resource base class. Swagger and TypeSpec doesn't allow property shadowing, from my test.
I didn't touch validate() here, since in this particular case, customer unlikely to define location or tags to override parent ones... If they were to, duplicate validation seems not a big issue..