Standardize resource ID terminology #4788

In DKAN we have an pseudo-entity called a DataResource (often just referred to as a "resource" in the code) that has three properties that together identify a unique instance: identifier, version and perspective. The actual entity is a resource_mapping, where each unique combination of these three things is a single entity, rather than the entities being versioned and fielded.

The "identifier" is an MD5 hash value, the version is (for now) a unix timestamp, and the perspective is one of: "source", "local_file" or "local_url". In different parts of the application we support passing two or three of these properties via a "compound" ID, with the format identifier__version__perspective. Throughout the code and docs we have very inconsistent terminology for these four things: "datastore UUID", "resource ID", "unique identifier", "compound ID", etc all make appearances, and "identifier" is used interchangeably to refer to different things.

Proposing that we establish a strict, consistent terminology for all this that we enforce throughout the code in variable names, argument names, and API parameters.

We may eventually refactor the resources into a proper entity, but a) that will be a long time from now, and b) that refactor will probably be easier if we have a more consistent schema/API/naming convention for these things, so it's clearer what needs to be swapped out in business logic throughout the application.

Let's use the comments thread here for brainstorming on the specific terminology.