fix #63711: no naturals on change to atonal key signature

[MarcSabatella]

I haven't run mtests yet; relying on Travis to do a first pass. I would plan to add some if nothing breaks. No hurry on merging this, but I welcome discussion.

My initial implementation of atonal key signatures just leveraged custom key signatures, making the case of a custom key sig with no symbols special. This doesn't work if we start adding naturals. So I have now moved to a more MusicXML-like implementation, where atonal key signatures are key of C but with a "mode" (a new attribute) of NONE. This also gives us a framework for modes of MAJOR & MINOR. The actual handling for the atonal key signatures is basically the same as before, but I no longer rely on them being custom or having no symbols - instead, I test mode == NONE directly (via a new isAtonal() function, analogus to isCustom()).

[MarcSabatella]

OK, I think I'm done now. I've added a vtest as well as updating an mtest to test the functionality. There was already a MusicXML import/export test, and it continues to pass.

In 2.0 & 2.0.1, atonal key signatures were represented as "custom" but with no accidentals. To maximize compatibility, I am retain the "custom" tag on these, but am also adding a "mode" tag, set to "none". 2.0 / 2.0.1 will simply ignore the mode tag and treat the atonal key signatures as they always have. But with my change, the layout code will create naturals as it would for other key signature changes.

I have also added checks for isAtonal() everywhere else it would be needed so that if it becomes useful, we could actually stop using the "custom" flag for atonal key signatures, and represent them as just ordinary signatures with a "mode" of "none". But to maximize compatiblity, I am keeping the "custom" flag on atonal key signatures for now.