details is an ambigue parameter name

the parameter name 'details' can mean different things in different API calls. These should be aligned and/or renamed. see the discussion in #3331

##### ISSUE TYPE
* Improvement Request

##### COMPONENT NAME

~~~
API
~~~

##### CLOUDSTACK VERSION

~~~
all
~~~

##### SUMMARY

| type of details field | class |
| - | - |
| | Commands: |
| Map | RegisterOAuthProviderCmd.java |
Map | BaseUpdateTemplateOrIsoCmd.java
List\ | ListHostsCmd.java
Map | UpdateZoneCmd.java
Map | CreateNetworkOfferingCmd.java
Map | UpdateBgpPeerCmd.java
Map | CreateBgpPeerCmd.java
Map | UpgradeSystemVMCmd.java
Map | ScaleSystemVMCmd.java
Map | UpdateStoragePoolCmd.java
Map | UpdateCloudToUseObjectStoreCmd.java
Map | AddImageStoreCmd.java
Map> | CreateSecondaryStagingStoreCmd.java
Map | AddObjectStoragePoolCmd.java
Map | CreateStoragePoolCmd.java
Map | ImportUnmanagedInstanceCmd.java
Map | AddGuestOsCmd.java
Map | UpdateGuestOsCmd.java
Map | CreateDiskOfferingCmd.java
| List\ | ListDomainsCmd.java
Map | CreateTemplateCmd.java
Map | GetUploadParamsForTemplateCmd.java
Map | RegisterTemplateCmd.java
List\ | ListTemplatesCmd.java
List\ | ListProjectsCmd.java
Map | UpgradeVMCmd.java
List\ | ListVMsCmd.java
Map | DeployVMCmd.java
Map | UpdateVMCmd.java
Map | RestoreVMCmd.java
| Map | ScaleVMCmd.java |
| List\ | ListAccountsCmd.java |
| Map | AddResourceDetailCmd.java |
| | Responses: |
| Map | TemplateResponse.java |
Map | NetworkOfferingResponse.java
Map | VolumeForImportResponse.java
String | DirectDownloadCertificateHostStatusResponse.java
Map | NetworkProtocolResponse.java
Map | UserVmResponse.java
Map | BgpPeerResponse.java
Map | DiskOfferingResponse.java
Map | NetworkResponse.java
String | CreateConsoleEndpointResponse.java
String | RouterHealthCheckResultResponse.java
Map> | DetailOptionsResponse.java
Map | HostResponse.java
String | UnmanageVMInstanceResponse.java

In addtion to these there are some details related parameters that also have different types i.e. details and some of them even as boolean.

There are two improvements to make here:
1. make sure there are no ambiguities for users when they encounter a in- or output field named “details”
2. make sure maintainers do not mix different patterns for the same basic functionality
the first being the more important one

In addition to all this there are backwards compatibility concerns. Some can be changed “under the hood” others will have to be marked as “deprecated" to the user and and copied into a in-/output field with a new name, only considering the old one if the new one is missing.

##### EXPECTED RESULTS
A clear pattern from both user and developer point of view.

Comece pela discussão em #3331 e pelo inventário nesta issue; em seguida, compare classes representativas da API, como RegisterOAuthProviderCmd.java, ListHostsCmd.java e TemplateResponse.java. Mapeie os diferentes campos de detalhes e identifique as restrições de compatibilidade retroativa. Considera-se concluído quando houver um padrão de nomenclatura consistente e acordado entre usuários e maintainers, com os campos deprecated identificados quando a renomeação não puder ser transparente.

Escrita pelo modelo de indexação a partir do texto da issue.