Fix over-writing library prologue

[xbauch]

when linking the cprover library. The default mode for this constructor of
stringstream is to over-write the string used in construction, which presumably
was not the intention here.

Note: until now there wasn't anything too interesting in the prologue except for
the string-abstraction define, which was ignored. But we might want more defines
in the future.

• Each commit message has a non-empty body, explaining why the change was made.
• Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[hannes-steffenhagen-diffblue]

#include <iostream>
#include <sstream>
int main(void) {
  std::ostringstream send_help{"SOS"};
  send_help << "WAT";
  std::cout << send_help.str() << '\n';
}

Try it online!

[thk123]

WAT is the point of this constructor...
A potentially more obvious fix might be

std::ostringstream library_text;
library_text << prologue

[hannes-steffenhagen-diffblue]

@thk123 In a slightly less humorous note, I can see uses for this (for example, if you need to guarantee some minimum width for the output so you add in a bunch of filler characters to override first), the “wtf” here is that this is the default, which I think few sane people would expect.

[xbauch]

std::ostringstream library_text(prologue);
library_text.seekp(0, library_text.end);

would also work.

[chrisr-diffblue]

I'd personally lean either towards the solution @thk123 suggested, or to the original solution @xbauch had in the PR. I think the alternative using seekp just looks even more odd :-) Though I appreciate the oddness comes from the C++ spec here.

[hannes-steffenhagen-diffblue]

Turning it off

[hannes-steffenhagen-diffblue]

And turning it on again

[thk123]

Superseded by #5285