Clarify restrictions for short codes

[bocops]

We seem to have the same or similar discussion about the availability of reference locations repeatedly. For example, the following three issues are currently open (and could be closed if this goes through):

• #398 - a suggestion to add predefined "localities" to the end of plus codes using another separator
• #461 - a request to have an "open set of anchors" that can be used world-wide
• #497 - a complaint that short codes are "a black box" that need to be opened by releasing the full "dataset" Google Maps uses for their generation of short codes, or at least a "high level abstraction of an algorithm" to be implemented on a different dataset to result in the same name / code prefix relation.

I assume there might be additional closed issues along those lines, and we've had similar discussions on the mailing list. The underlying problem seems to be that the following caveats for short code generation and usage are either glossed over or not spelled out at all in the various parts of our documentation:

• Short codes must be interpreted relative to some reference location. This reference location needs to be shared knowledge between all parties involved, or it needs to be transferred with the short code.
• If the reference location is given as a location name (e.g. XXXX+XX CITY_NAME), which is this project's suggested way of doing things, then the recipient will have to translate this location name back into coordinates. Specifically, short codes will not work offline, unless the recipient has a lookup table available for all location names they might encounter.
• Providing such lookup table is not within the scope of this project.
• If a short code is generated using one provider, then there are no guarantees of being able to decode it via another provider. Specifically, short codes generated on Google Maps will probably have to be entered into Google Maps on the receiving device, or make use of Google Maps APIs.

Please comment if changes along those lines would not be welcome and merged if provided via PR. Unless that is the case, I will try to suggest doc changes along those lines in the coming days.