need to settle on markup for SPARQL keywords, `<var>`, `<expr>` in text

[TallTed]

Originally posted by @TallTed and @hartig in #259 (comment)

[@hartig] @TallTed, I included all your suggestions except for the one about code-fencing the keyword SELECT. That one I left out because, in this part of the spec, there are a lot of mentions of SPARQL keyword and none of them is code-fenced. Thus, code-fencing just this one mention of "SELECT" would be inconsistent with respect to the rest of this part of the spec.

[@TallTed] I understand your thought process here, and I generally agree with consistency. However, I believe that all SPARQL keywords in all sections should be presented as code, just as you can see in lines 8622 and 8718 of this PR. I think the error is that "this part of the spec" does not already do so.

[@hartig] I agree. But, again, if we implement such a change, it should be done in a dedicated PR.

[@TallTed] (I also think that the <b> and some <code> seen in the document through this PR are incorrect. I'm fairly certain that the variable <code>v</code> should become variable <var>v</var>.

[@hartig] Yes, and then also in the table below that paragraph, as well as in the paragraphs below the table.

[@TallTed] I don't know what the best marksup would be for Let <b>P</b>, <b>P1</b>, and <b>P2</b> be graph patterns nor and <b>E</b>, <b>E1</b>,..., through <b>En</b> be expressions, but I'm quite certain it's not <b>.)

[@hartig] These should all be <var>..</var>. Another issue here is that the table doesn't even use all these variables; it uses expr instead.

Decisions made via this issue will need to be propagated across all documents, not just SPARQL-query.

[afs]

While there are some features in reSpec, there isn't one for "keyword" that works within running text (that I can find). <var> has it's own highlighter.

A start would be to put <span class="keyword">...</span> around keywords. Later, we can add the javascript for <keyword>.

A note of caution:

We have multiple strands of work going on.Format changes can lead to merge conflicts, as happened recently adding <var> inside a <pre> block in one PR that another PR was changing - that was minor and isolated but at scale, it is all too easy to loose changes in resolving conflicts. A stable target at an agreed point-in-time is much easier and will reduce mistakes.