replaced function argument 'string' by 'const string&' where it makes sense to avoid unnecessary co…

replaced function argument 'string' by 'const string&' where it makes sense to avoid unnecessary copying of 'string' objects.

Measurements on x86_64 (i7-2760QM, 2.40GHz) Fedora 19 with g++ 4.8.1, with
configure --enable-optimising --disable-debugging; tests run 10 times, average
elapsed time compared (/usr/bin/time)

* Bach, Concerto in E major or violin and strings, BWV 1042 (Mutopia source),
  38 pages:
  $ lilypond score.ly -> master: 15.4s, with patch: -0.1%
* lilypond regression tests (1153 .ly files):
  $ lilypond *.ly -> master: 276.6s, with patch: -2.5%

[Keith, 2013-09-06 21:42:23]

I tried to go through and look for unintended consequences. 
I guess f(const string &s) is conventional in C++, so I guess this looks good to
me.

https://codereview.appspot.com/13537043/diff/1/lily/file-name-map.cc
File lily/file-name-map.cc (left):

https://codereview.appspot.com/13537043/diff/1/lily/file-name-map.cc#oldcode32
lily/file-name-map.cc:32: s = file_name_map_global[s];
Maybe the intent was to change the parameter in the caller,
lily/parser-scheme.cc:121, but probably not.

[fred1995, 2013-09-07 04:44:02]

https://codereview.appspot.com/13537043/diff/1/lily/file-name-map.cc
File lily/file-name-map.cc (left):

https://codereview.appspot.com/13537043/diff/1/lily/file-name-map.cc#oldcode32
lily/file-name-map.cc:32: s = file_name_map_global[s];
Then it would require 'string &s'.

[dak, 2013-09-10 01:12:48]

https://codereview.appspot.com/13537043/diff/1/lily/file-name-map.cc
File lily/file-name-map.cc (left):

https://codereview.appspot.com/13537043/diff/1/lily/file-name-map.cc#oldcode32
lily/file-name-map.cc:32: s = file_name_map_global[s];
On 2013/09/07 04:44:02, fred1995 wrote:
> Then it would require 'string &s'.

I checked.  Uses are few and obviously don't intend such a change to occur.