Fixes problem with -dpreview cropping staff brackets (Issue 3386)

This is a simple revert of the problematic lines in the original commit - I've not done any study as to why these are the problem, but this change makes -dpreview function as it should once again when there are braces and brackets present.  I've pixel-compared and the only change is a very minor shift in the bar number on beam-broken-difficult.ly

[PhilEHolmes, 2013-05-31 12:29:46]

Please review.

[dak, 2013-05-31 12:54:51]

On 2013/05/31 12:29:46, PhilEHolmes wrote:
> Please review.

Color me surprised.  Patch set 3 from the original patch is called  "Patch Set 3
: Removes evil code from C++, replaces with happy defaults in Scheme".  Your
partial revert only removes the "happy defaults in Scheme" without reinstating
the "evil code from C++".  Now the question is what the "evil code from C++" was
supposed to be doing, and whether merely removing the "happy defaults in Scheme"
will cause problems.

Mike, are you reading this?

[Keith, 2013-06-06 03:29:16]

>  Patch set 3 from the original patch is

not relevant.  In the previous round of that review I had suggested marking the
start brace as 'cross-staff' which generally means "my size/position/shape is
not final until staves are spaced on the page".  Unfortunately I forgot that
'cross-staff' has the side effect or "leave me out of EPS extents" which has
been a problem for years.

Without the 'cross-staff' indication, we need to explicitly say to estimate the
horizontal extent of the staff-brace, and similar items, before its stencil is
finalized.

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

https://codereview.appspot.com/9894043/diff/1/scm/define-grobs.scm#newcode2252
scm/define-grobs.scm:2252: 
(horizontal-skylines . ,grob::simple-horizontal-skylines-from-x-extent)