v.db.connect: Add JSON support

[NishantBansal2003]

Fixes: #6014

This PR adds JSON support to the v.db.connect module. The JSON output looks like:

• With -p flag:

[
    {
        "layer": 1,
        "name": "roadsmajor",
        "table": "roadsmajor",
        "key": "cat",
        "database": "$GISDBASE/$LOCATION_NAME/$MAPSET/sqlite/sqlite.db",
        "driver": "sqlite"
    },
......
]

• With -c flag:

[
    {
        "name": "cat",
        "type": "INTEGER"
    },
    {
        "name": "MAJORRDS_",
        "type": "DOUBLE PRECISION"
    },
......
]

This PR includes the following changes:

1. Adds a format option with plain, csv, and json modes for output formatting.
2. Adds format = csv option; the -g flag is now deprecated.
3. Adds tests covering each of the new formats.
4. Adds a Python example to the documentation for parsing JSON output.
5. The default format is plain for the -p flag, and CSV for the -g and -c flags.

[wenzeslaus]

Going deeper into this, I now see that #6014 does not capture all the complexity.

[wenzeslaus]

Thanks for the updates. I have tested the parameter combinations I raised up and they work great now.

I have three further comments, but I don't know if we need to pursue them:

1. v.db.connect streets -cp ignores -c and prints the same as -p.
2. v.db.connect streets -c format=csv prints columns in order sql_type, name. Would name, sql_type be better? But I know that this would require even more code to keep the backwards compatibility.
3. Default separator: We may have this issue elsewhere too, but I realized that only now. CSV should by default have comma, not pine. v.db.select deals with that in the way that by default, the separator is not set, for plain format and in legacy mode, it uses pipe, but for explicit format=csv it uses comma. For format=json, the separator can be ignored, but I think v.db.select complains because now it was set explicitly and it does not make sense.

[petrasovaa]

Thanks for the updates. I have tested the parameter combinations I raised up and they work great now.

I have three further comments, but I don't know if we need to pursue them:

1. v.db.connect streets -cp ignores -c and prints the same as -p.

This could be simply solved using the parser rules, no?

2. v.db.connect streets -c format=csv prints columns in order sql_type, name. Would name, sql_type be better? But I know that this would require even more code to keep the backwards compatibility.

I would say low priority

3. Default separator: We may have this issue elsewhere too, but I realized that only now. CSV should by default have comma, not pine. v.db.select deals with that in the way that by default, the separator is not set, for plain format and in legacy mode, it uses pipe, but for explicit format=csv it uses comma. For format=json, the separator can be ignored, but I think v.db.select complains because now it was set explicitly and it does not make sense.

I believe we attempted to handle that in the other cases. So yes, this should be fixed.

[NishantBansal2003]

Thanks for the updates. I have tested the parameter combinations I raised up and they work great now.

I have three further comments, but I don't know if we need to pursue them:

1. v.db.connect streets -cp ignores -c and prints the same as -p.
2. v.db.connect streets -c format=csv prints columns in order sql_type, name. Would name, sql_type be better? But I know that this would require even more code to keep the backwards compatibility.
3. Default separator: We may have this issue elsewhere too, but I realized that only now. CSV should by default have comma, not pine. v.db.select deals with that in the way that by default, the separator is not set, for plain format and in legacy mode, it uses pipe, but for explicit format=csv it uses comma. For format=json, the separator can be ignored, but I think v.db.select complains because now it was set explicitly and it does not make sense.

Addresses all of these in the latest commit, hope that makes sense. Also, for (2), the code was not that much, so I added that case as well.

[wenzeslaus]

Markdown doc can spec json, instead of text, for JSON examples.

[wenzeslaus]

This is good to go. Thank you for the fine tuning.

Sorry for the noise with the highlight language for the examples. I didn't realize it is clearly meant as a Python print. It should be good to go now.