Naming display modules and addons

[ecodiv]

There has been a discussion in pull request #74 in the addon repository about how to name add-ons / functions that create plots/image. I have not a strong opinion on this, but think some good points have been made. Because a pull request may not be the best place to continue this discussion, I am copying the main arguments here.

From @wenzeslaus: "name of the d.rast.boxplot should be different: "Although it deals with visualization, it is not a display command, so perhaps r prefix. The d prefix is reserved for the tools which are using the system of display drivers and monitors and can be combined with each other. This tool is separate from that. In that context, it is similar to tool such as m.nviz.image or r.scatterplot. On the other hand, there is no standard for naming visualization tools and thinking about this one as display (d.) command in general is not wrong, so I'm wondering if there is a better way of naming things here."

From @ecodiv: Good point. I used this name in line with the names of d.vect.colhist and d.vect.colbp add-ons. I have no preference, but I think there should be some consistency.

From @mlennert: "I don't have a strong opinion on this. It really depends on whether you think that the command is first about displaying something or first and foremost about analyzing a type of map. I used d. as I felt the former to be more important as plotting is about displaying, but I can understand the argument that boxplots and histograms are as much, if not more, about analysis.
So feel free to rename any of these modules as you see fit."

From @ecodiv; I'll rename the addon for now to r.boxplot. If at some point, the decision is made for a specific and above all consistent naming convention, it may be anyway better to do that for all concerning modules at once.

From @ninsbl: " I wonder if it wouldnt help users to find dedicated plotting functions if that would be indicated more systematically in the module name. Either as a new group of commands (e.g. starting with p., like p.rast.boxplot) or sub-group (e.g. r.plot.poxplot, v.plot.*` ...). That would also help grouping such functions (also new, future ones).

That said, I think the technical concept behind the d prefix is (even) less prominent in the heads of users than it is in the heads of developers. So, my guess is that there is a bit of a trade-off regarding technical consistency vs. UX consistency"

From @wenzeslaus: "See the notebook (Binder, GitHub) or doc for grass.jupyter, an object of Map will render true display commands (one or more) into an image which you can either show in the notebook or save with a unified interface. Similarly with d.mon in command line where the image goes, e.g., to wx0 window or a PNG image. Using d.vect.colbp won't have the promised effect.

The display command and driver system is more specific than visualization (regardless of how we define the terms for ourselves in other contexts). Its equivalent outside of GRASS GIS is, for example, Matplotlib, gnuplot or GMT. In GRASS GIS, it is parallel to m.nviz.image (visualization in 3D) or ps.map (cartography outputs in PostScript). This should be definitively communicated in a better way. Suggestions welcome.