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.

Commencez par la discussion dans #3331 et l’inventaire de cette issue, puis comparez des classes représentatives de l’API telles que RegisterOAuthProviderCmd.java, ListHostsCmd.java et TemplateResponse.java. Faites correspondre les différents champs de détails et identifiez les contraintes de rétrocompatibilité. Le travail est considéré comme terminé lorsqu’un modèle de nommage cohérent et approuvé par les utilisateurs et les maintainers est défini, avec les champs obsolètes identifiés lorsqu’un renommage ne peut pas être transparent.

Rédigé par le modèle d'indexation à partir du texte de l'issue.