Allows for easier creation of many Lilypond objects via Scheme. (issue 7009047)

[dak]

All of this is absolutely devastatingly horrible code that is not
reconcilable with sane per-session semantics and tampers with LilyPond
internals in a way that has bleed-over effects into future files in the
same command line.

In addition, the interfaces into the exposed internals are absolutely
horrific and cryptic and don't make any sense as a user interface.

This is taking everything that is broken with
input/regression/scheme-text-spanner.ly, magnifies it to a number of
other cases, and gives it a bad interface.

No, no, and no again.  Extensibility in this area would be nice, but
pulling out LilyPond's innards into the public without a proper design
is no substitute for that and totally a step in the wrong direction.
None of these ad-hoc interfaces can sensibly be guaranteed to survive
any evolution of LilyPond's operation since they don't interface to
functionality, but rather to the current internals.

If people want to poke LilyPond's internals with a stick, of course they
can do so with all bad side effects including everything breaking
possibly on the next update.  But there is no point giving them a stick
with a handle for that if there is no way in which we can guarantee the
handle working for longer or better than the stick does.


https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly
File ly/property-init.ly (right):

https://codereview.appspot.com/7009047/diff/2001/ly/property-init.ly#newcode682
ly/property-init.ly:682: defineEventClass =
Absolutely awful interface here.  No.

https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm
File scm/define-grobs.scm (right):

https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode2695
scm/define-grobs.scm:2695: (define (register-grob-name x)
No.  This is an interface with heavy session bleedover characteristics:
as long as a symbol is not garbage-collected (for example, because it is
referenced anywhere as a symbol in a totally non-grob context), it will
remain defined between sessions.

First the internals need to be redefined in a manner allowing for sane
per-session behavior before any exposed public interface is offered for
that.

https://codereview.appspot.com/7009047/diff/2001/scm/define-grobs.scm#newcode2703
scm/define-grobs.scm:2703: (completize-grob-entry x))
No, this will cause heavy bleedover effects between sessions.

https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm
File scm/define-music-types.scm (right):

https://codereview.appspot.com/7009047/diff/2001/scm/define-music-types.scm#newcode758
scm/define-music-types.scm:758: (define-public (make-music-descriptions
descriptions)
Unsuitable for a public interface because of session bleedover.

https://codereview.appspot.com/7009047/