tests: Call t.remove and g.remove once with multiple inputs as list

[echoix]

This PR should help squeeze out a couple of seconds of testing time by calling t.remove or g.remove once with multiple inputs separated by a comma, when all other parameters are the same. For t.remove, I combined the layers in the inputs argument with a comma, and for g.remove, I combined the names of the files of the name argument. I referred to https://grass.osgeo.org/grass85/manuals/t.remove.html and https://grass.osgeo.org/grass85/manuals/g.remove.html.

I tried to keep using a manual string concatenation to be as close as the usage shown in the docs. However, when changing g.remove usages, I saw that, at least in gunittests self.runModule, name could be passed a list or a tuple for a similar effect. I tried to follow the call chain for runModule, but couldn't pinpoint with precision where that conversion happened. So, I kept the changes safe and close to the existing tests. If you can show me how safe it is to pass a list (or tuple), some changes could be made simpler.

Last week I benchmarked a single test in t.rast.accumulate and these changes had a measurable impact, being 1.18x faster (when combined with removing unused SimpleModule import, like filed in #4521).

I still kept the test prefix in the title, even if some changes are for benchmarks, and one change in utils/thumbnails.py

[petrasovaa]

I tried to keep using a manual string concatenation to be as close as the usage shown in the docs. However, when changing g.remove usages, I saw that, at least in gunittests self.runModule, name could be passed a list or a tuple for a similar effect. I tried to follow the call chain for runModule, but couldn't pinpoint with precision where that conversion happened. So, I kept the changes safe and close to the existing tests. If you can show me how safe it is to pass a list (or tuple), some changes could be made simpler.

I am pretty sure you can use lists here.

[wenzeslaus]

+1 for the lists. If self/cls.runModule does not work, you can switch to gs.run_command. Main reason for runModule was to track execution and align with assertModule and neither of those is particularly strong reason to keep using runModule now. Otherwise, the string concatenation would be done with ",".join([item1, item2, item3]).

[echoix]

+1 for the lists. If self/cls.runModule does not work, you can switch to gs.run_command. Main reason for runModule was to track execution and align with assertModule and neither of those is particularly strong reason to keep using runModule now. Otherwise, the string concatenation would be done with ",".join([item1, item2, item3]).

If it doesn't work, there's a bigger problem, as it is used at multiple places.

I'll try to do the changes next time I have time to code :)