Discussion/problem: how to split and classify obliques in square notation

When classifying glyphs in the IC, we try to break neumes down into their smallest components to keep the classification as simple and generalizable as possible. This is particularly important for compound neumes, because we can't possibly have a separate classification for every iteration of every three/four/five-note neume out there. I am currently working on a little test to see whether YOLO can take care of this splitting business (see https://github.com/issues/created?q=is%3Aissue+state%3Aopen+archived%3Afalse+author%3A%40me+sort%3Acreated-desc&issue=DDMAL%7Cmothra-annotator%7C23).

However, even if we get YOLO to split neumes into their smaller components, obliques remain a problem. For two reasons:

1. Obliques are always attached to at least one other neume component;
2. Obliques are often attached to that other neume component in such a way that separating them with two rectangular boxes doesn't work. See the following examples (all from Einsie folio 045v):

You can see that it's not possible to draw a box around only the oblique without including that little punctum that comes after (in pictures 4 and 6, you can separate the first punctum, but not the second). The ideal scenario would be to isolate all obliques, so that our only oblique classifications would be `neume.oblique2`, `neume.oblique3`, and `neume.oblique4`. But I don't see how this is possible with our current tools.

I see two solutions:

1. Ignore this type of neume! Oh well! There aren't _that_ many, so we can choose to accept the margin of error. Obliques that can be separated from the rest of their neume will be, and for the rest, the NIC will classify them as best it can and corrections can be made in Neon.
2. Add separate classifications for all three-note neumes that go oblique+punctum. The issue here is that the oblique can go down a second, a third, or a fourth, and the following punctum can go up a second, a third, or a fourth, which is (quick math) nine more classifications. To illustrate, the neumes I uploaded above (once you remove the first punctum from neumes 4 and 6) would be:
- `neume.porrectus34`
- `neume.porrectus32`
- `neume.porrectus32`
- `neume.porrectus22`
- `neume.porrectus22`
- `neume.porrectus33`

So the question is, do we prefer keeping the square notation classification spreadsheet reasonable sized and accept a certain margin of error, or accept that the classification spreadsheet become giant in the name of accurate neume identification? @kyrieb-ekat @annamorphism @Yueqiao12Zhang please share with me your thoughts.

(If you're wondering why I haven't talked about this until now, it is because I was in denial.)