Delete LocalizedString::appendnl.

[BillyONeal]

I believe appendnl hails from a time when we thought we were going to be much more rigid about manipulation of LocalizedStrings as tokens. There are localized strings which themselves contain newlines. There are also formatted data strings, such as error message blocks join'd with \n, that we need to insert into localized messages. We also aren't likely to ever want to change our newlines to \r\n or something like that :)

To that end, I think both original reasons for this to exist are gone, and it should go away.

I think we should go all the way to removal rather than only removing the guidelines about it, because I think we, and contributors, will be confused if it exists and is relatively meaningless in the same way that people are confused (and use) std::endl today. The fact is that newlines aren't special in our LocalizedString structures, and we should be honest about that in our design.

Contrast/note: append_indent must stay, and we must add a plain std::string version of that, to ensure consistency in how we handle indenting, as this is likely to be actually ambiguous (as opposed to newlines which are always and forever \n in vcpkg).

[ras0219-msft]

I do see several cases of:

1. .append_nl().append_indent()
2. .append_indent().append_raw(...).append_nl()
3. .append_indent().append(...).append_nl()

It might make sense to introduce convenience functions to combine these.

[BillyONeal]

It might make sense to introduce convenience functions to combine these.

I agree that some convenience functions may make sense. I'm still not sure what the right balance is though, since we end up creating the cross product of effect functions for every variant, etc. I think we should complete the localization project with this API and expand that cross product only where we see it being useful most of the time.

Thanks for the review!