Issue 5590: Remove dead code from Dot_formatting_problem

https://sourceforge.net/p/testlilyissues/issues/5590/

Nothing was using Dot_formatting_problem::best(), which was good
because the function that was apparently intended to find the best
configuration was not keeping track of the associated best score.

[Carl, 2019-10-29 19:38:23]

I'm torn on this patch.  Obviously, the current case is not good.  We shouldn't
have dead code around.  But it is possible that we should in fact use a "best"
for the dot formatting problem, and the failure to do so may lead to some of the
random formatting issues we see in our regtests.

It's not clear to me that the optimal solution to this is to remove the best. 
It might be better to keep the best and put in a FIXME that points out it is
unused.

I did some work a few years a go on the dot_column code, but never got it ready
for submission.  I will look into my code tonight when I get home and see how I
handled the "best" issue.

My bottom line is that the current system is definitely broken.  I'm not sure if
the best fix is to remove the unused code (which will hide the potential
brokenness of the dot_column creation) or to highlight the unused code as being
broken.

[Dan Eble, 2019-11-01 17:18:34]

On 2019/10/29 19:38:23, Carl wrote:
> My bottom line is that the current system is definitely broken.

Yes, and the thing that bugs me most is that it reallocates memory per
candidate, for no benefit.

> I will look into my code tonight when I get home and see how I
> handled the "best" issue.

If you need more time, I won't be offended if we keep this patch in "countdown"
a bit longer; however, I don't want the best to become the enemy of the good. 
If someone later wants to return to this, it's not hard to revert it in git, nor
is it hard to reimplement a loop to find the best of a series of things
properly.

[Carl, 2019-11-01 17:46:51]

On 2019/11/01 17:18:34, Dan Eble wrote:
> On 2019/10/29 19:38:23, Carl wrote:
> > My bottom line is that the current system is definitely broken.
> 
> Yes, and the thing that bugs me most is that it reallocates memory per
> candidate, for no benefit.
> 
> > I will look into my code tonight when I get home and see how I
> > handled the "best" issue.
> 
> If you need more time, I won't be offended if we keep this patch in
"countdown"
> a bit longer; however, I don't want the best to become the enemy of the good. 
> If someone later wants to return to this, it's not hard to revert it in git,
nor
> is it hard to reimplement a loop to find the best of a series of things
> properly.

OK. let's move ahead with the patch as proposed.  If I have stuff that uses
"best", it's already not in master, and my patch can add it.

If not, it's really not doing much  (if any) good to have NOP code hanging
around.

[GiandomenicoFisichella, 2019-11-03 08:05:39]

On 2019/10/29 19:30:29, Dan Eble wrote: