Bar lines: fixing custom type and generated management

There are some inconsistencies in the current management of bar line `_generated` flag and user-modified type:

- Bar lines created by the New Score Wizard are flagged as non-generated, as well as bar lines of measures manually **appended** by the user, while bar lines of measures **inserted** are flagged as generated.
- If a generated bar line is individually changed of typed, it remains flagged as generated, it is not saved and the change is lost upon saving and re-loading.
- The management of the internal flag `BarLine::_customSubtype` is not always consistent.
- The `Measure::_endBarLineGenerated` flag was not always restored properly by undo.

This PR introduces the following fixes:

- The `_generated` flag is consistently used for bar lines whose type can be reconstructed from the context and then do not need to be saved to the output file.
- Normal bar lines are **always** created as generated: initially created by the Wizard, manually appended or inserted.
- Bar lines with custom type (i.e. different from the type which can be expected according to the bar line context) are always flagged as non-generated, ensuring the custom type is written to the output file.
- The `Measure::_endBarLineGenerated` flag is stored by `ChangeEndBarLineType()` and restore upon undo.
- Some test reference scores, based on the inconsistent bar line `_generated` flag, have been uniformed.

Notes:

- Tests about measure (and then bar line) appending, inserting and relative undo's are already included in the `tst_parts` test suite.
- Some inconsistencies remain in the management of custom bar line span and of system-initial bar lines: for the sake of simplicity, they will be dealt with in separate PR's.
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.
Add default value for BarLine::updateGenerated()
Fix most issues for continuous view panel
Merge pull request #1281 from mgavioli/barline_custom_type_and_generated

Bar lines: fixing custom type and generated management
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.
Adds to the Articulation class 4 symbols for lute tablature fingerings.

The Articulation class has been chosen because these symbols behave much like other articulations. The class already contains a number of symbols which are not really neither articulations or ornaments.

The new symbols have been grouped together with the somehow related cello thumb position symbol, at the end of the ArticulationType enum and set to `ArticulationShowIn::TABLATURE` only.

A specific case for them has been added in the `Chord::layoutArticulation()` method, as they do not follow the rules of other articulations.
fix #32161: false collisions with crossstaff notes
Further color changes
Brighter colors, as requested
fix #32331: lower case minor chord issues on save/reload
fix #32471: crash on setting drumset note to auto
fix #32416: crash on note entry in voice>1 at end of score
update Gonville, add GonvilleText

fallback to BravuraText
add vtests for Gonville

modeled after the Bravura tests
update vtests for Emmentaler and Bravura
Merge pull request #1295 from MarcSabatella/32416-last-tie-crash

fix #32416: crash on note entry in voice>1 at end of score
Merge pull request #1291 from MarcSabatella/32161-staffmove-collision

fix #32161: false collisions with crossstaff notes
Merge pull request #1293 from MarcSabatella/32331-lower-harmony

fix #32331: lower case minor chord issues on save/reload
Merge pull request #1287 from vgstef/ContinuousPanel

Fix most issues for continuous view panel