Handle endings in TSV -> music21 conversion

[malcolmsailor]

In a #1412 (comment), I proposed the following two options for resolving the issue of 1st and 2nd endings being written to the same measure in TSV conversion:

1. insert ending brackets for the 1st and 2nd endings (based on the volta column present in the DCML tsv files) but without any associated repeat bars---this is what I already more or less implemented.
2. put the 1st (or 1st and 2nd, if there is a 3rd ending, etc.) ending into some sort of metadata as I suggested above.

In discussion at MarkGotham/When-in-Rome#58 (comment), @MarkGotham expressed a preference for option 1, and no one else seemed to express a preference, so that's what this PR implements.

One remaining issue (raised in the comments of my code) is

# Should we warn the user that, although we're writing
# repeat brackets, we aren't writing repeat signs since
# the .tsv file doesn't tell us where the forward repeat
# should be?

[coveralls]

Coverage increased (+0.001%) to 93.048% when pulling 2dd6168 on malcolmsailor:tsv_endings into cddb104 on cuthbertLab:master.

[MarkGotham]

Great thanks @malcolmsailor !

Wrt repeat signs, are we talking about the inclusion of :|| in a case like:

m2a V :||
m2b V

Surely we want that included? I don't see what'd be gained by omitting it.

Apologies if I've got the wrong end of the stick!

[malcolmsailor]

Yes, I do mean omitting that repeat bar. Because we don't know where the corresponding forward repeat bar would be, so including it would lead to incoherent repeats.

Moreover we don't necessarily know where the first ending repeat-bar should go either. For example, consider a TSV looking something like this

mn  chord   volta
1   I             
2   V       1
2   I       2
4   I

This is ambiguous between what could be written in romanText as

m1 I
m2a V :||
m2b I
m3 I
m4 I

and

m1 I
m2a V
m3a V :||
m2b I
m3b I
m4 I

[mscuthbert]

This looks good to me, but see note on typing. If the TSV team would be willing to add mypy typing for the module, it'd help me from not needing to do it later (getting frustrated, etc., because I don't know the code well, etc.) -- it mostly means not allowing "None" for variables that are clearly meant to be strings.

[mscuthbert]

mentioning this because it's an addition, but it's the same for all of these. It would be better if the default for these was not None but '' because this sets the typing of the usage later. We're heading towards > 90% typing in mypy so it would be very helpful if these could be typed and if the typing was not str | None but just str which requires a '' default.

[mscuthbert]

I notice for instance, that you're not doing "and thisChord.volta is not None" but instead just "and thisChord.volta" so setting the default to an empty string won't cause a problem.

[malcolmsailor]

OK added some type hints in a new commit. Also initialized to the empty string where that didn't cause any hassle.

[mscuthbert]

looks good to me. Merging. Happy New Year!