Fix #32396 : Bugs in TAB note inputs.

Several inconsistencies accumulated in TAB note input during recent updates.

The main point is that currently the pitch, fret and string of a note -- if all are known -- must be changed in a single step; otherwise, the fretting algorithm intervening after each step notices they are inconsistent and refrets (potentially) the whole chord, which leads to loosing the fretting entered by the user.

A specific `undoChangeFretting()` function has been added, to be used with TAB's instead of `undoChangePitch()` when all the new fretting data (pitch, fret and string) are known in advance.

Also, the fretting algorithm has been changed to be more conservative, i.e. to keep the current note fretting (potentially entered by the user) as much as possible.
Fix #32261 : Local edit of bar line affects all bar lines

The use case detailed in the original issue (http://musescore.org/en/node/32261) was the following:

If edit mode is entered for a bar line with user-edit span (e.g. a tick) and then exited without any edit, as Ctrl has never been pressed, the edit is assumed to be global and the span of all the bar lines is changed to that specific bar line span.

Adds the following fixes:

- Entering and exiting bar line edit mode and doing nothing actually does nothing whatsoever.
- Any further span edit of a bar line whose span is already user-customized is assumed to be local to that bar line only. This makes using [Ctrl] for any further editing of a single bar line redundant.

Additionally:

- Any change in the span of system-initial bar line is always assumed to be local and no longer affects all the bar lines, as before.
Merge pull request #1288 from mgavioli/Fix_32261_local_barline_edit_affects_all_barlines

Fix #32261 : Local edit of bar line affects all bar lines
Merge pull request #1283 from mgavioli/Fix_32396_tab_note_input

Fix #32396 : Bugs in TAB note inputs.