Standardize parameter naming based on service name; relegate legacy parameter names to OCI_CLI_PARAM_ALIASES

Consider standardizing convention for parameter names according to service name. For example, this command is predictable using the service name in part for the key parameter name

oci network drg get --drg-id <value> #--drg-id is obvious for service drg

However, this command uses a non-predictable key parameter

oci network route-table get --rt-id <value> #would expect route-table service uses --route-table-id parameter not --rt-id

I would expect this to use a similar convention and instead require --route-table-id as input. There are many existing services that follow this convention well. For example:

oci network cross-connect get --cross-connect-id <value>
oci network local-peering-gateway get --local-peering-gateway-id <value>
oci compute-management instance-configuration get --instance-configuration-id <value>

I see this throughout and suggest deprecating mismatched inputs in favor of more verbose yet aligned names. For example:

• Deprecate oci network route-table get --rt-id in favor of --route-table-id
• Deprecate oci network dhcp-options get --dhcp-id in favor of --dhcp-options-id
• Deprecate oci network ip-sec-tunnel get --ipsc-id in favor of --ip-sec-tunnel-id
• …and so on

As is done with other verbose parameter names, default entries for OCI_CLI_PARAM_ALIASES in ~/.oci/config could be created to ease the transition. Certainly, each person may choose their own custom aliases still as needed.

Start by inventorying the listed OCI CLI commands and the existing OCI_CLI_PARAM_ALIASES behavior; the issue does not name implementation files or tests. Define the complete set of mismatched parameters and the transition expectations. Done means service-aligned parameter names are supported across the affected commands while legacy names remain available through aliases.