Defect: openapi uses camel case instead of snake case

[ashcherbakov]

The current openapi (automatically generated by https://github.com/tendermint/starport) uses camel case in all requests and response, while snake case is expected in most of the cases in DCL.

We need to fix that, so that openapi matches the real query format.

Acceptance Criteria

• Fix openapi to match the real content
• Extend DEV docs mentioning how to generate openapi properly
• [Optional] Investigate why starport generates the code like this.

Example of the issue
For API /dcl/model/models/31/100

{
    "model": {
        "vid": 31,
        "pid": 100,
        "device_type_id": 1,
        "product_name": "DEMO",
        "product_label": "DEMO",
        "part_number": "DEMO001",
        "commissioning_custom_flow": 0,
        "commissioning_custom_flow_url": "",
        "commissioning_mode_initial_steps_hint": 0,
        "commissioning_mode_initial_steps_instruction": "",
        "commissioning_mode_secondary_steps_hint": 0,
        "commissioning_mode_secondary_steps_instruction": "",
        "user_manual_url": "",
        "support_url": "",
        "product_url": "",
        "lsf_url": "",
        "lsf_revision": 0,
        "creator": "cosmos1clsrmjxx07k9u70wgem3q9ve9s978adgmhnt0m"
    }
}

But openapi show the following:
https://zigbee-alliance.github.io/distributed-compliance-ledger/?urls.primaryName=DCL#/Query/ZigbeeallianceDistributedcomplianceledgerModelModel

{
  "model": {
    "vid": 0,
    "pid": 0,
    "deviceTypeId": 0,
    "productName": "string",
    "productLabel": "string",
    "partNumber": "string",
    "commissioningCustomFlow": 0,
    "commissioningCustomFlowUrl": "string",
    "commissioningModeInitialStepsHint": 0,
    "commissioningModeInitialStepsInstruction": "string",
    "commissioningModeSecondaryStepsHint": 0,
    "commissioningModeSecondaryStepsInstruction": "string",
    "userManualUrl": "string",
    "supportUrl": "string",
    "productUrl": "string",
    "lsfUrl": "string",
    "lsfRevision": 0,
    "creator": "string"
  }
}

[ashcherbakov]

Fixed in #276