Updating param name from connector_i_ds to connector_ids in RFmx VNA

[RahulBenaka]

What does this Pull Request accomplish?

For APIs in VNA with parameter name as connectorIDs (in metadata), the name was appearing as connector_i_ds in proto and respective service files. This PR aims to resolve that naming issue and correct it to connector_ids. This is achieved by adding "IDs" in the ADDITIONAL_ACRONYMS of VNA gRPC metadata in grpc-scrapigen repo and leverage that to generate 'grpc_name' field to add the appropriate name to be reflected in proto and respective service files

Why should this Pull Request be merged?

This name change from connector_i_ds to connector_ids is required for legibility and this will help us to maintain python gRPC code for RFmx use the appropriate naming convention.

What testing has been done?

Manually inspected generated files.
Copied files from grpc-device-scrapigen/out/rfmxvna/export/ to grpc-device/source/codegen/metadata/nirfmxvna/ and hardcoded these new param names by using 'grpc_name' field and built grpc-device successfully.
Manually inspected nirfmxvna.proto file.

[astarche]

Normally we fix this by adding a transform in scrapigen that updates grpc_name in the functions.py file. I have never used functions_addon (I think) since I've worked on grpc-device. Maybe that was originally for some MI APIs where functions.py was an external source-of-truth. But for RFmx, we are already generating the metadata for grpc-device from scrapigen, so we can include it in the primary functions.py metadata.

I wonder if just adding IDs or something similar to ADDITIONAL_ACRONYMS would fix this? Maybe this case is slightly different from other analyze_acronyms use-cases. You can also have a custom transform that patches a specific parameter name with a grpc_name.

[RahulBenaka]

Hey thanks for the hint. I have used the existing ADDITIONAL_ACRONYMS for VNA in grpc-scrapigen to fix the param name and generate the appropriate grpc_name.

Could you please review my new changes. Thank you.