Issue 3186: fix clef transposition alignment

Until now, numbers indicating clef transposition (for example
in \clef "G_8") were simply centered against the clef glyph.
This was not optimal, because clef glyphs aren't symmetrical
- for example the hook of the treble clef isn't exactly at its
horizontal center, and thus the octavation number shouldn't
be exactly centered.

This commit allows to specify alignment separately for each
clef, taking into account their individual characteristics.
Alignments are stored in clef-alignments property.
Remove stray BOM from chords.itely

Introduced with commit f739a44f91a0b7ef5f634b6c4ca5b45c988798c1
Update version in Editorial to avoid \relative -> \relative c' conversion
Fix issue 3826

Commit 2d3a5d87166caa13feb036e23086b0d4f23283f4 let
scripts/auxiliar/update-with-convert-ly.sh call the non-existent
Makefile target "make pythonmodules" instead of "make python-modules".
Correct \version statement in clef modifier regtest
Release: bump VERSION_DEVEL.
PO: update template.
Release: update news.
Release: bump Welcome versions.
Release: bump VERSION.
Issue 4066: Clean lily/include/lily-proto.hh from unused/undefined classes

This is the result of running

sed -i -e "$(sed -n s'/^class\s\+\([^;]*\);.*$/\1/p' lily/include/lily-proto.hh |while read i;do git grep -l "\(class\|struct\)\s\+$i" lily|grep -q -v lily/include/lily-proto || echo "/^class $i/d";done)" lily/include/lily-proto.hh
Issue 4063: Interpret < > and << >> in \chordmode

There is no compelling reason not to do so, and having < > available
allows stuff like

\chordmode { \clef bass <c> c/e <g,> c/e }

or other ways of explicitly spelling out some not-really chord material.
Doc: Appendix - Articulations and Ornamentation - part 3

Issue 1189

Create Texifo @multitable entries for the
List of Articulations appendix.

As there are a lot of separate scripts being
documented this Issue is going to be split
into multiple, smaller, parts to aid in the
review process. Part 2 was commit 4d6f2a27cc

This is part 3 and while not strictly
'Articulations and ornamentations' covers
the percussion scripts.

I have also set the @code{} script examples into
the same column as the @lilypond examples; saving
a significant amount of wasted page space. I have
removed unnecessary lilypond-book variables making
the texinfo code less noisy.
Fix lilypond-book include paths (issue 4046)

Rewrite paths relative to the lily-output-dir or the output dir
depending on which one is being used. Always use forward slashes
since this is what lilypond expects, even on Windows.
Fix references when using --use-source-file-names (issue 4046)
Add reg test (issue 4046)

Test nested include files and use lybook-testdb during make test.
Add missing trailing newline
Issue 3072: Nested overrides get confused with multiple contexts in play

The main problem with nested overrides lies not as much with the
override (which can be done reasonably well) but rather with the
corresponding reverts.  Detecting and undoing a previously established
nested override by its effects on an alist, particularly when nested
overrides may be present at several different levels in several
different contexts and/or stack depths and may be undone in different
order from being established, is a complex problem.  It is complex
enough that it is not clear that a satisfactory solution does even
exist: at least LilyPond's implementation breaks down for a number of
test cases.

The approach of this implementation is to not even try reverting nested
overrides from looking at their effects on the final result.  Instead
nested overrides like

\override Staff.TextSpanner.bound-details.left.text = #"foo"

are not done by creating an assembled alist element for TextSpanner
looking like

(bound-details . ((left . ((text . "foo") ...)) ...))

with ... filled in from other parts of the alist (which may change
independently at a later point of time) but rather by using
(bound-details left text) itself as a key and thus storing

((bound-details left text) . "foo")

as the representation of the override.  Consequently, reverting an
override with the same nested property path is straightforward.  Neither
the action of overriding nor of reverting now require referring to or
updating any part of the property stack outside of the current context.

The downside is that an actual reference to the resulting grob alist
requires expanding the nested overrides at the time of creating a grob
or otherwise asking for ly:context-grob-properties.

Since issue 2507 encapsulated grob property access into the
Grob_property_info algorithm container structure relying on data stored
in context properties of elements of type Grob_properties, changing the
respective algorithms can be facilitated completely in those classes.

In order to provide similarly efficient access and reasonable caching
and just-in-time reevaluation of previously computed values,
Grob_properties needed to be significantly extended in size.
Fix severe context/grob property mixup in event-listener
input/regression/override-nest.ly needs matched \override/\revert