lib/parser: Use project for G_OPT_M_LOCATION

[wenzeslaus]

Standard option G_OPT_M_LOCATION which creates option named location now creates option named project. Each module using G_OPT_M_LOCATION without further modifications has its own entry in in the renamed options file for backwards compatibility.

New usage of g.mapset:

> g.mapset project=nc_basic_spm_grass7 mapset=user1

Still works:

> g.mapset location=nc_spm_08_grass7 mapset=user1

The latter produces a warning:

WARNING: Please update the usage of <g.mapset>: option <location> has been
         renamed to <project>

g.mapset --h:

Changes/reports current mapset.

Usage:
 g.mapset [-clp] mapset=name [project=name] [dbase=path] [--overwrite]
   [--help] [--verbose] [--quiet] [--ui]

Flags:
  -c   Create mapset if it doesn't exist
  -l   List available mapsets and exit
  -p   Print current mapset and exit

Parameters:
   mapset   Name of mapset (default: current search path)
  project   Project (location) name
    dbase   GRASS GIS database directory

This applies to:

• g.mapset
• r.proj
• i.ortho.elev
• g.download.location
• v.proj

[HuidaeCho]

@wenzeslaus Do you consider adding new G_OPT_M_PROJECT and switching to it eventually in GRASS 9?

[wenzeslaus]

Yes. That fits with the general plan of adding "project" to the API and then gradually removing usage of "location" internally.

[cmbarton]

Note the inconsistencies in how the terms Mapset and Location are written in this and other places: mapset, MAPSET, and Mapset. Since we are changing terminology, this is a good opportunity to standardize how these important terms are written.

As suggested in #2993 and other places, I suggest that we capitalize the first letter and use lower case for the rest of the letters in all descriptions, labels, and documentation--i.e., Mapset and Project--wherever possible. This reduces confusion when people read about these important terms.

For command-line arguments, I suggest keeping everything in lower case letters of course.