Adds links to algebraic syntax symbols within the Property Paths eval section

[hartig]

This is the next step related to #228

This PR makes the following changes, all within Section 18.5 Property Path Patterns.

1. Given the new option to directly link to the symbols of the algebraic syntax (as added by the previous PR, Adds explicit definition of the algebraic syntax #227), this PR applies this option in Section 18.5 Property Path Patterns now. That is, every mention of such a symbol in this section is now linked to the definition of that symbol.
2. The PR adds <var>..</var> markup within that section.
3. The PR also addresses Rename eval function for Property Path Patterns #218 by renaming the eval function defined in this section to ppeval. In fact, I have slightly changed the related notation further: Every mention of the eval function in this section contained the Path operator; i.e., mentioning something like eval(Path(X, PP, Y)) everywhere. As it is always Path and nothing else, I decided to simplify the notation by dropping Path. Hence, now it is something like ppeval(X, PP, Y) everywhere.
4. The PR adds issue markers for two issues that I discovered while working on this PR. These issues are Inconsistencies in definition of evaluation of property path with sequence #266 and Bug in definition of evaluation of property path with OneOrMorePath #267
5. The PR reorganizes the introductory paragraphs of the section (in particular, moving the example from the end of the introductory part to a more relevant place) and adds text there to make more clear that the translation of Property Path Patterns is actually done in two steps (Sec.18.3.2.3 and Sec.18.3.2.4).

To make reviewing this PR easier for you, I tried to keep the rest of the text of the section (after the introductory paragraphs) as is and only add the relevant markup there. (In this sense, I would prefer edit suggestions only on the things that this PR actually changes. I noticed a bunch of language and punctuation issues in the parts that this PR touches, but I think it is more helpful to ignore them for now and come back to them in a separate PR later.)

---

Preview | Diff

[TallTed]

I noticed a bunch of language and punctuation issues in the parts that this PR touches, but I think it is more helpful to ignore them for now and come back to them in a separate PR later.)

The trouble with this "do it later" approach is that it tends to result in a LARGE amount of polishing that is needed when a WG is under significant time pressure. The existing changes in this PR will lead to a similar level of merge conflict as may result from applying language and punctuation fixes now to the same areas. Those merge conflicts will be no more difficult to resolve with the language and punctuation fixes than they will be to resolve without them.

That said, I will resist the urge to add such fixes to this PR until and unless you agree that this is a good place for them, and I will only comment on the existing changes herein.

[TallTed]

Good to go, with my last tweaks above.

[hartig]

Thanks @TallTed ! I have applied your proposed change.

@afs and @kasei are you okay with merging this PR?

[afs]

Mostly taboput presentation of definitions, trying to get rid of scroll bars.

One question about eval vs ppeval.

One note that RDF Concepts now defines "nodes".

[hartig]

Mostly taboput presentation of definitions, trying to get rid of scroll bars.

I have applied all these changes.

One question about eval vs ppeval.

I have responded to that one inline (directly as a response to the comment).

One note that RDF Concepts now defines "nodes".

I have applied your edit suggestion for that one as well.