When there is no standard output (stdout), return None, instead of returning the ToolResult object.
This creates expected result in interactive console and similar cases (notebooks and doctest-tested documentation),
i.e., no result for tools which produce no text output (all tools which create spatial data such as r.slope.aspect or r.grow).

Closes OSGeo#6272.

This also adds description of the returned value to the generated documentation of each tool. We don't have a 'returns' section which would apply to all interfaces, so I went with imperfect soltion of adding 'Returns:' block at the end of Parameters section. This mimics how the block looks like in other Python doc, copying the 'Parameters:' block, but our block does completely fit with our Parameters section and breaks the hiearchy as it is nested under Parameters (but it is not a section heading, so not visible as heading or in toc). It also leave out the indent for the description because we can do this indent only for the first line, so a multiline paragraph would not create a consistent look.

It also fixes couple spelling and syntax issues in the doc and adds missing tests related to no stdout.

While this makes even more sense with OSGeo#5878 (returning NumPy arrays), it would make sense even without it.

When there is no standard output (stdout), return None, instead of returning the ToolResult object.
This creates expected result in interactive console and similar cases (notebooks and doctest-tested documentation),
i.e., no result for tools which produce no text output (all tools which create spatial data such as r.slope.aspect or r.grow).

While this makes even more sense with #5878 (returning NumPy arrays), it would make sense even without it.

Closes #6272.

Provides consistent_return_value parameter to signal that a result should not switch to None, but always be an object. Using long, but very explicit consistent_return_value as a name.

This also adds description of the returned value to the generated documentation of each tool. We don't have a 'returns' section which would apply to all interfaces, so I went with imperfect soltion of adding 'Returns:' block at the end of Parameters section. This mimics how the block looks like in other Python doc, copying the 'Parameters:' block, but our block does completely fit with our Parameters section and breaks the hiearchy as it is nested under Parameters (but it is not a section heading, so not visible as heading or in toc). It also leave out the indent for the description because we can do this indent only for the first line, so a multiline paragraph would not create a consistent look.

It also fixes couple spelling and syntax issues in the doc and adds missing tests related to no stdout. Also improves the generated tool documentation: Parameters have space on both sides of colon.

This is adding r.pack files (aka native GRASS raster files) as input and output to tools when called through the Tools object. Tool calls such as r_grow can take r.pack files as input or output. The format is distinguished by the file extension.

Notably, tool calls such as r_mapcalc don't pass input or output data as separate parameters (expressions or base names), so they can be used like that only when a wrapper exists (r_mapcalc_simple) or, in the future, when more information is included in the interface or passed between the tool and the Tools class Python code. Similarly, tools with multiple inputs or outputs in a single parameter are currently not supported.  

The code is using --json with the tool to get the information on what is input and what is output, because all are files which may or may not exists (this is different from NumPy arrays where the user-provided parameters clearly say what is input (object) and what is output (class)). Consequently, the whole import-export machinery is only started when there are files in the parameters as identified by the parameter converter class.

Currently, the in-project raster names are driven by the file names. This will break for parallel usage and will not work for vector as is. While it is good for guessing the right (and nice) name, e.g., for r.mapcalc expression, ultimately, unique names retrieved with an API function are likely the way to go.

When cashing is enabled (either through use go context manager or explicitly), import of inputs is skipped when they were already imported or when they are known outputs. Without cache, data is deleted after every tool (function) call. Cashing is keeping the in-project data in the project (as opposed to a hidden cache or deleting them). The parameter to explicitly drive this is called use_cache (originally keep_data).

The objects track what is imported and also track import and cleaning tasks at function call versus object level. The data is cleaned even in case of exceptions. The interface was clarified by creating a private/protected version of run_cmd which has the internal-only parameters. This function uses a single try-finally block to trigger the cleaning in case of exceptions. 

While generally the code supports paths as both strings and Path objects, the actual decisions about import are made from the list of strings form of the command.

From caller perspective, overwrite is supported in the same way as for in-project GRASS rasters.

The tests use module scope to reduce fixture setup by couple seconds. Changes include a minor cleanup of comments in tests related to testing result without format=json and with, e.g., --json option.

The class documentation discusses overhead and parallelization because the calls are more costly and there is a significant state of the object now with the cache and the rasters created in the background. This includes discussion of the NumPy arrays, too, and slightly improves the wording in part discussing arrays.

This is building on top of #2923 (Tools API, and it is parallel with #5878 (NumPy array IO), although it runs at a different stage than NumPy array conversions and uses cache for the imported data (may be connected more with the arrays in the future). This can be used efficiently in Python with Tools (caching, assuming project) and in a limited way also with the experimental run subcommand in CLI (no caching, still needs an explicit project). There is more potential use of this with the standalone tools concept (#5843). The big picture is also discussed in #5830.