Avoids calling pure calculations too far downstream and avoids triggering quanting too far upstream (issue 12951044)

[k-ohara5a5a]

Of course this is two commits.

I do not know of any reason to distinguish the concept of 'cross-staff'
from your new
height_depends_on_grobs_from_another_vertical_
      axis_group()
In most cases, 'cross-staff' means exactly that the height (Y-extent)
depends on staff-spacing.

Could you mark the relevant object as 'cross-staff' when the cross-staff
item is added to it 'support', rather than search through its support
later?

I am completely stumped how skipping some objects in computing skylines
for staff-spacing has anything to do with quanting.



https://codereview.appspot.com/12951044/diff/1/lily/side-position-interface.cc
File lily/side-position-interface.cc (right):

https://codereview.appspot.com/12951044/diff/1/lily/side-position-interface.cc#newcode274
lily/side-position-interface.cc:274: // In the case of a stem, we will
find a note head as well
The comments are out of date

https://codereview.appspot.com/12951044/diff/1/lily/side-position-interface.cc#newcode284
lily/side-position-interface.cc:284: && !is_direction
(e->get_property_data ("direction")))))
Now you skip *all* stems whose direction is still uncertain, while
before you skipped only cross-staff stems of uncertain direction.
That seems fine, but makes a lot more sense if the decisions about stems
are all together in the next "if()continue" down below.

https://codereview.appspot.com/12951044/