Make text in dynamics default to italic

This is actually related to #279703: Using ctrl+a then delete to edit tempo text keeps custom formatting in that part of the problem is the custom formatting applied to the existing dynamics. In addition, though, it seems we aren't picking up the italics in the text style in imported 2.x scores.

Well the font of the p and f characters for the dynamics text isn't actually italic...but rather seems to just appear italic because that is how the font for those special characters p and f actually are. Indeed double clicking on the dynamics, and looking at the text toolbar reveals that italics button is not depressed:

And if I do select the middle f for instance and change it to actually be italic, then it gets extra slanted:

It seems that the problem is not that the custom formatting is applied, but rather is mismatch between what the text toolbar is telling the user the font of the text at the cursor actually is versus what the font style for dynamics is.

The issue is that if you type additional text after the "mp" or whatever, it doesn't get the correct font. Which is why I say it's related to (if not duplicate of) [ #279703]. User shouldn't be punished for the fact that dynamics contain special characters; he should be able to add new characters at beginning or end and get the font specified in the Inspector.

a space too much, #279703: Using ctrl+a then delete to edit tempo text keeps custom formatting

My PR for #281831: text cursor before first character of a text element or before a special character of text aren't initialized to text element's default (https://github.com/musescore/MuseScore/pull/4588) seems to fix this, so I'm marking as duplicate of that underlying issue.

So while my PR does fix the underlying issue, it doesn't address my earlier comment https://musescore.org/en/node/279702#comment-886681 that dynamics are really not actually italic but just look like they are. It seems that aspect is by design. A user could select dynamic text and then apply italics so that it becomes extra italicized...

Ok, yeah, that is what I've come to accept.

If you are on windows and want to test, the build is: https://ci.appveyor.com/api/buildjobs/cosx8h7m0cfoaaja/artifacts/MuseSc… ...it seems that it takes a long time for code to be approved for merging.

There is one thing left that I'm wondering about...if user manually changes selects one of these special characters in a text element and manually makes them a different size, then as my PR reinitializes the cursor to the text element's default when places before a special character, that means additional typed text will be of the default size:

Of course I could add special handling to not use the default size, but only use the default italicization and font, but that seems to be too much special handling, so I think better to just leave that behavior as is, considering that MuseScore is already playing tricks to the user in not actually having the dynamics be italicized even though they look italicized.

ok...is that a problem, and is that even related to the issue being addressed?

ok...I don't think it is really a problem either.

The important things are:

• If you double-click in the dynamic any type additional text, the additional text must be italics, and the formatting of the original symbol must not change.
• If you mess around with custom formatting and then click the "reset to style / remove custom formatting" button, additional text must revert to italics, the original symbols must revert to their default rendering.

All other concerns (such as whether or not the symbols can be made "extra italic") is secondary to those requirements.

I think this regression is due to partly due to the fact that the way dynamics are stored has changed. It used to be that all dynamics were treated equally and encoded using a combination of <sym>p</sym> or <sym>f</sym> within the <text> element, whereas now there are special <p/> and <f/> elements, and symbols are only used for "custom dynamics". The new implementation is more similar to MusicXML, but I'm not sure that MusicXML was right on this issue because it means that <sym>p</sym><sym>p</sym> (e.g. in "pp sempre") is not recognised as containing <pp/>.

bullet 1 is fixed.

bullet 2 is a separate issue from this issue report and isn't changed or addressed by my PR. I did notice what I consider not ideal behavior: if I click a dynamic text, and remove custom formatting, the original symbols actually change to become more italic. But I think you should make a separate issue report for that.

> "think this regression is due to partly due to the fact that the way dynamics are stored has changed"

Well the regression is fixed by my PR apparently (https://github.com/musescore/MuseScore/pull/4588) so please review it.