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.

Start with the discussion in #3331 and the inventory in this issue, then compare representative API classes such as RegisterOAuthProviderCmd.java, ListHostsCmd.java, and TemplateResponse.java. Map the differing details fields and identify the backwards-compatibility constraints. Done means an agreed, consistent naming pattern for users and maintainers, with deprecated fields identified where renaming cannot be transparent.

Written by the indexing model from the issue text.