Issue 5659: Clean up to_string () etc.

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

C++11 provides std::to_string () overloaded for basic integer types.
This set of changes removes similar global functions from flower to
avoid ambiguity.

There is some other general clean-up in here, but it's all related to
strings.

1: Remove some unused string-related functions

2: Remove String_convert::char_string
Where necessary, construct a std::string directly.

3: Delete ::to_string (const string&)

4: Delete ::to_string(char, ssize_t)

5: Delete ::to_string (bool b)

6: Delete ::to_string (i) for various integer types

7: Finally remove deleted ::to_string () overloads

8: Remove Interval<T>::T_to_string ()
This has an example of a technique that was not previously usable
because of ambiguity between std::to_string () and ::to_string ().

[Dan Eble, 2020-01-11 20:05:30]

Remove String_convert::char_string

[Dan Eble, 2020-01-11 20:06:22]

Delete ::to_string (const string&)

[Dan Eble, 2020-01-11 20:06:55]

Delete ::to_string(char, ssize_t)

[Dan Eble, 2020-01-11 20:07:17]

Delete ::to_string (bool b)

[Dan Eble, 2020-01-11 20:07:58]

Delete ::to_string (i) for various integer types

[Dan Eble, 2020-01-11 20:08:38]

Finally remove deleted ::to_string () overloads

[Dan Eble, 2020-01-11 20:09:26]

Remove Interval<T>::T_to_string ()

[lemzwerg, 2020-01-11 22:20:35]

LGTM, thanks!

https://codereview.appspot.com/583320043/diff/581420044/flower/file-name.cc
File flower/file-name.cc (right):

https://codereview.appspot.com/583320043/diff/581420044/flower/file-name.cc#n...
flower/file-name.cc:124: s += ext_;
any reason to use two lines?  In other files you use a single line for similar
things.

[Dan Eble, 2020-01-12 00:20:03]

https://codereview.appspot.com/583320043/diff/581420044/flower/file-name.cc
File flower/file-name.cc (right):

https://codereview.appspot.com/583320043/diff/581420044/flower/file-name.cc#n...
flower/file-name.cc:124: s += ext_;
On 2020/01/11 22:20:34, lemzwerg wrote:
> any reason to use two lines?  In other files you use a single line for similar
> things.

s += EXTSEP; // append a char to s
s += ext_; // append a string to s

— vs. —

s += EXTSEP + ext_;
     \___________/
     make a string
\________________/
 append it to s

Either one could involve memory allocation, but I deemed it more
likely in the latter case.  I don't have reason to suspect this is a
performance bottlenck, but given that I had to touch the line, and
that it wasn't a major rewrite, I decided to try to improve it.

[lemzwerg, 2020-01-12 07:44:42]

> s += EXTSEP; // append a char to s
> s += ext_; // append a string to s
> 
> — vs. —
> 
> s += EXTSEP + ext_;
>      \___________/
>      make a string
> \________________/
>  append it to s
> 
> Either one could involve memory allocation, but I deemed it more
> likely in the latter case.  I don't have reason to suspect this is a
> performance bottlenck, but given that I had to touch the line, and
> that it wasn't a major rewrite, I decided to try to improve it.

I'm not sure that it is an improvement.  Today, compilers use very good
optimization tools; I can imagine that the performance of both lines is exactly
the same – or that the one-line version performs even better since the compiler
can handle the memory allocation internally in an optimized way.  Only a
profiler can give a clear answer, and this is most certainly dependent on the
platform and the compiler.

I thus favor code that is easiest to understand by the user, or which looks
nice.  Normally, I very much favor a vertical flow of source code, but in this
particular case the compact one-liner looks easier to comprehend.

[Dan Eble, 2020-01-12 19:30:07]

Werner's feedback