IBM Cloud API Grouping

The upstream openapi-generator builds an entire gem per openapi spec file. This leads to a huge number of gems but there wasn't much choice.

The new/downstream IBM openapi-sdkgen builds an API class per openapi specification which allows for logical grouping of API classes per gem.

As we move towards the newer style of autogenerated gem we should re-evaluate the gem structure.

I see a few possibilities:

1. Group APIs by high-level API group, e.g.: Platform, Compute, Storage, etc... (some APIs are in multiple groups)
2. Group by low-level API group, e.g.: Resource Controller has resource_controller/resource_controller_v2 and resource_controller/resource_manager_v2
3. Have all APIs in one monolithic ibm_cloud gem
4. Some combination of the first three, e.g. maybe group all platform APIs into one gem, then separate ibm_cloud_vpc / ibm_cloud_power / ibm_cloud_object_storage

Review the current gem layout and the upstream openapi-generator output, then compare them with the downstream IBM openapi-sdkgen model described here. Done means selecting and documenting a gem-grouping strategy from the alternatives, including how APIs that belong to multiple groups should be handled.