Add data carrying graph types

[bwetherfield]

This PR implements a Node-analog to weighted graph implementations, namely graphs where each node is assigned a piece of data. A system of protocols and structs mirror those of the ordinary graphs but with this added data carrying feature.

The PR is motivated by various use cases in the PitchSpeller modules, where we want

• a graph structure where nodes are not only labeled but also carry Pitch values
• a graph structure where nodes are assigned a Tendency value

In the above cases and in other usage, the data carrying graph types will give us O(1) lookups of data associated with the nodes thanks to the dictionary storage of the data.

[bwetherfield]

@jsbean, this will be really handy to pull in while I am working on the PitchSpeller! Basically just felt I needed this... needs tests but they should be easy to pull over from *GraphTests

[jsbean]

Indent this guy.

[jsbean]

This is looking very compelling. To clarify, is the main affordance of these structures to be able to store non-Hashable values along with nodes? Have you run into this in the PitchSpeller process?

Given the following values:

let value: Int // (Hashable)
let data: String // (Hashable)

How are these two structures different?

let dg = DataGraph<Int,String>()

and

struct DataNode {
    let value: Int
    let data: String
}
extension DataNode: Equatable { }
extension DataNode: Hashable { }
let g = Graph<DataNode>()

[jsbean]

The two use cases given:

• a graph structure where nodes are not only labeled but also carry Pitch values
• a graph structure where nodes are assigned a Tendency value

could potentially be implemented with the current Graph structures, but wrapping up the label and the associated data into a struct. This would still afford O(1) access.

I could be missing something crucial here, though. Lemme know, @bwetherfield !

[bwetherfield]

I'm going to go back to NotationalModel and hopefully push something that motivates this more concretely!

[jsbean]

Is NotationModel PR #123 a bit that would benefit from this?

[bwetherfield]

Yes, and further NotationalModel PR #126...

So, in that PR, I've switched things from being Array-oriented to more Dictionary-oriented when it comes to Pitch. AssignedNode is unscathed. It does yield an asymptotic improvement to spelling all the pitches injected in (post-processing after the network algorithms).

But...

I haven't checked whether instead of passing around structures of the form pitches = [Int: Pitch], the same improvements can be made with something of the form pitches = [IndexedPitch] where

struct Pitch {
    let index: Index
    let value: Pitch
}

Judging from the fact that I could leave AssignedNode be (without loss), IndexedPitch may end up being just as good!

Let me know your reflections, @jsbean!