avoid the term "remote" when talking of "context by reference"

While we want to fight the misunderstanding that "@context": "https://..." requires you to make an HTTP request,
the current text of the specs (syntax and api) pushes readers into that direction.

• Section 3.1 "Contexts" of the syntax spec starts with an "inline" context, then states:

  "Contexts can either be directly embedded into the document (an embedded context) or be referenced using a URL. Assuming the context document in the previous example can be retrieved at https://...,"

  then continues by calling them "remote contexts"

• This is pursued in the API spec, esp. in Section 9.4 "Remote Document and Context Retrieval", where the output of a document loader is called RemoteDocument.

I suggest that we should avoid as much as possible the term "remote", which strongly points towards "download over the network", to something more abstract.

Proposals:

• external context (in the sense that it is external to the document that reference it)
• replace RemoteDocument with DereferencedDocument (suggested by @TallTed), emphasising that there are many ways of "dereferencing" (from cache, from an internal registry of "well-known" contexts...)

Read Section 3.1, "Contexts," in the syntax specification and Section 9.4, "Remote Document and Context Retrieval," in the API specification. Inventory the uses of "remote" and "RemoteDocument," then resolve the terminology choice and update both specifications consistently; completion means the revised wording no longer implies that references require network retrieval.