WriteLinesToFile improvements

[jeffkl]

Fixes #

Context

I was working on something else entirely and saw some easy improvements to make in WriteLinesToFile.

Changes Made

1. File.ItemSpec is being accessed 14 times. I think the implementation will make a new string each time.
2. It has two code paths, overwrite vs not and both code paths were creating the directory
3. The contents of the file to write are stored in a StringBuilder with no initial capacity. I took a wild guess and set to lines * 64
4. If no lines are specified, a StringBuilder is no longer created and instead it uses string.Empty
5. Since the contents are now stored in a string on all code paths, the comparison of the current vs new is simplified since string.Equals() will check the length
6. Reduced nesting by inverting the if (File != null) statement

Testing

From what I can tell, the existing tests are good.

Notes

[Copilot]

Pull Request Overview

This PR refactors the WriteLinesToFile.Execute() method to improve code readability and maintainability through better control flow structure and reducing nesting levels.

• Inverted the null check for File to use early return
• Extracted filePath variable from File.ItemSpec using FileUtilities.NormalizePath at the beginning of the method for consistent reuse
• Removed redundant null checks and improved code organization by flattening nested conditions

[rainersigwald]

1. I think the implementation will make a new string each time.

Only if it's got a % in it, by my read

msbuild/src/Shared/EscapingUtilities.cs

Lines 68 to 74 in eb9c2d2

	// If there are no percent signs, just return the original string immediately.
	// Don't even instantiate the StringBuilder.
	int indexOfPercent = escapedString.IndexOf('%');
	if (indexOfPercent == -1)
	{
	return trim ? escapedString.Trim() : escapedString;
	}

(but still no need to check that every time)