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.

Comienza con la discusión en #3331 y el inventario de este issue; después, compara clases representativas de la API, como RegisterOAuthProviderCmd.java, ListHostsCmd.java y TemplateResponse.java. Mapea los distintos campos de detalles e identifica las restricciones de compatibilidad hacia atrás. Se considera terminado cuando exista un patrón de nomenclatura coherente y acordado por usuarios y maintainers, con los campos obsoletos identificados cuando el renombrado no pueda ser transparente.

Escrito por el modelo de indexación a partir del texto del issue.