consistency in key/value combo representations

[mhelvens]

Right now there is inconsistency in how key/value combos are represented throughout the API:

• When adding vertices and edges, the arguments are given separately, like key, value and from, to, value.
• When iterating over vertices and edges, they are yielded as [key, value] and [from, to, value] respectively.
• In the recently supported constructor arguments, vertices and edges are to be represented as [key, value] and [[from, to], value]. This is also used to store vertices and edges in certain exception objects.

The third is going to be standard in the next version. Such consistency will ensure full compatibility between these parts of the API. [[from, to], value] is chosen over [from, to, value] because that way, vertices and edges can always be distinguished, even when the vertex has a string value and the edge has no value at all.

Old notation will still be supported where possible. The main breaking change will be in edge iterators.

[mhelvens]

The [from, to] representation also goes for methods that need to pass it to callbacks:

• equals
• mergeIn
• clone
• transitiveReduction