Improve performance through improved mapping / caching

[wustep]

See prior discussion in #25.

Perf is slow and we're rerendering graphs every toggle, which is not ideal.

Renames / deletes require re-rendering, but toggles shouldn't. Plus our mapping functions could be condensed. We could make renames more efficient by directly going through and renaming the mapping, but this adds some more complexity to the code too and isn't a big perf win.

"Perf is probably caused by there being 3 separate mapping functions and them being pretty slow. We can probably do 1 run-through of the data to create mappings, and maybe combine two of them and do filtering better? Not sure" @wustep

"I'm sure we could perform all the data analytics the first time we load in a midi file and store the results in midiFiles, so we're not doing it every time we render a graph. That said, we'd have to change up a lot of end points." @jrg94

[wustep]

This is kinda a stretch goal, because in practice, users probably shouldn't be toggling graphs back and forth, renaming them a ton, etc., they'll typically make a file configuration and then spend the rest of the time examining the graph.

We could just add a loading spinner for now and call it a day for the sake of priorities

[wustep]

Did a LITTLE bit in #32 but not a ton, created mapping variable to store mappings instead of populating each time graphX functions are used

[wustep]

One source of slowness is d3.min and d3.max functions and unnecessary filtering.

If we know that the array is sorted, d3.min is slow since it searches the whole mapping.

[wustep]

BIG TODO improvement to toggling:

Instead of repopulating mapping, etc., just add some class to all elements from that midi file, and hide/show that class.