g.findfile: Add JSON support

[NishantBansal2003]

Fixes: #6005

This PR adds JSON support to the g.findfile module. The JSON output looks like:

{
	"name": "elevation",
	"mapset": "PERMANENT",
	"fullname": "elevation@PERMANENT",
	"file": "/grassdata/PERMANENT/cell/elevation"
}

This PR includes the following changes:

1. Adds a format option with shell, and json modes for output formatting.
2. -n is ignored and -l returns an error when using JSON format. If -t is unset and nothing is found, return success in JSON format.
3. Adds tests covering each of the new formats.
4. Adds a Python example to the documentation for parsing JSON output.

[petrasovaa]

It was not in the original issue, but please also change the python wrapper gs.find_file in python/grass/script/core.py to use parse_command with json, it should simplify the code slightly. Thanks!

[NishantBansal2003]

Traceback (most recent call last):
  File "imagery/i.cluster/testsuite/test_i_cluster.py", line 53, in setUp
    if self._signature_exists():
  File "imagery/i.cluster/testsuite/test_i_cluster.py", line 61, in _signature_exists
    sig_file_path = os.path.join(
  File "/usr/lib/python3.10/posixpath.py", line 76, in join
    a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not NoneType

Not sure, but it looks like using parse_command with JSON in find_file is not backward compatible. So, maybe we either need to use the old version of find_file or use an empty string ("") instead of null in the JSON.

[wenzeslaus]

There is couple options here:

1. Leave find_file as is. The modern way would be to use the g.findfile with JSON directly in user code and not use the find_file wrapper. The find_file wrapper can stay exactly the same.
2. The find_file wrapper can loop through the dictionary and replace None with "" for backwards compatibility, while keeping the better representation of nothing in JSON (null/None).
3. Consider the usage which fails a bad usage, fix the places which fail, and let (force) users do the same. The i.cluster test suggests that this is bad usage: find_file tells you the path when the element exists. If it does not, the code should not use the path. Here, the code ignores that info and proceeds as if it would always receive the path and does its own tests. It just happens to work because the relative path also doesn't exist. This related to a deeper issue with g.findfile which is a test of presence and it resolves the paths - it find the elements in the right mapsets and it also provides absolute paths to internal files, so that's actually 3 related but distinct things. On top of that, it seems that signatures don't have a good way of testing presence, so there is a whole new ad-hoc function function there _signature_exists.

My choice here is number 2. It transitions to the new code while keeping 100% backwards compatibility and we can resolve the questionable usage separately.