Clarify client traversal of role delegation graph

Spec v1.0.19 Section 5.6.7 describes how the client should traverse the delegation graph to update the targets role. The wording on cycle avoidance could use some clarification.

The spec says:

If this role has been visited before, then skip this role (so that cycles in the delegation graph are avoided)

A "role" in this context could either refer to 1) a delegated role (a node in the delegation graph) or 2) a role entry in the roles array of the DELEGATIONS object, which represents not a role, but a delegation from one role to another (a directed edge in the delegation graph).

As a result, there are two ways the traversal could be interpreted:

1. As we're traversing the delegation graph, skip nodes (roles) that have already been visited. This avoids visiting any one role twice, and produces the most intuitive pre-order traversals for graphs where some nodes have multiple parents (i.e. when the graph is not a tree). However, it's not true cycle detection and we may actually want to consider every edge, since different edges leading to the same role may represent different conditions of delegation (e.g. different keys, different paths, etc.).
2. As we're traversing the delegation graph, skip edges (delegations) that have already been visited. This follows the typical definition of cycle detection. However, it produces counter-intuitive "pre-order" traversals for graphs that aren't trees, and this interpretation is not obvious from the wording in section 5.6.7.

Below are two concrete examples.

Example A:

Example B:
(assume B's outgoing edges/delegations are ordered as [A, D]

cc: @trishankatdatadog

Start with Spec v1.0.19, Section 5.6.7, and compare its cycle-avoidance wording with Examples A and B. Resolve whether traversal tracks visited roles or delegations, then clarify the section so the intended behavior for shared nodes, cycles, and delegation conditions is unambiguous.