feature/fix-interval-entry

This PR fixes an issue with "no key" analysis of chords and in particular the intervals above the bass. The issue is that several chords map to the same interval entry that appears in the analysis table, but there seems to be a bug where depending on the order of the notes, the mapping is incorrect (i.e. a chord maps to "74" instead of "47" as expected).

The issue is in the `getIntervalsAboveBass(notes)` function, which obtains the correct intervals of the notes above the bass note, but doesn't ensure that the ordering is correct. The solution is to sort the intervals after they are obtained and then convert them to the entry string (basically just mash the intervals above the bass together so intervals [4,7] map to entry "47").

Concrete example: 
- Notes [65,69,72] should map to entry "47" because those are notes [F/5,A/5,C/6] with pitch classes 0,4,7. The bass is F, pitch 0 and the resulting entry string is "47."
- Notes [53,69,72] should map to entry "47" because those are notes [F/4,A/5,C/6] with pitch classes 0,4,7. The bass is F, pitch 0 and the resulting entry string is "47."
- Notes [53,60,69] should map to entry "47" because those are notes [F/4,C/5,A/5] with pitch classes 0,7,4. The bass is F, pitch 0, so the result *should* be entry string "47", but instead the entry string is "74."

So this PR fixes that issue and also refactors several supporting/related methods and includes a unit test for the method that was fixed.

@jazahn Can you review this?