feat: Add culture for Insert and Append

[linkdotnet]

Closes #276

[Copilot]

Pull request overview

This PR adds culture support to the Append and Insert methods for ISpanFormattable types in the ValueStringBuilder library. The change addresses issue #276, which requested the ability to specify culture (or use InvariantCulture) when formatting values. The implementation adds an optional formatProvider parameter that defaults to null, and when null, uses CultureInfo.InvariantCulture to ensure consistent, culture-independent formatting behavior.

Changes:

• Added optional formatProvider parameter to Append<T> and Insert<T> methods for ISpanFormattable types
• Updated internal AppendSpanFormattable and InsertSpanFormattable methods to use the provided format provider, defaulting to InvariantCulture when null
• Added comprehensive test coverage for both culture-specific formatting and InvariantCulture default behavior

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated no comments.

File	Description
src/LinkDotNet.StringBuilder/ValueStringBuilder.Append.cs	Added formatProvider parameter to Append<T> method and updated implementation to use it with InvariantCulture fallback
src/LinkDotNet.StringBuilder/ValueStringBuilder.Insert.cs	Added formatProvider parameter to Insert<T> method and updated implementation to use it with InvariantCulture fallback
tests/LinkDotNet.StringBuilder.UnitTests/ValueStringBuilder.Append.Tests.cs	Added tests verifying culture-specific formatting and InvariantCulture default behavior
tests/LinkDotNet.StringBuilder.UnitTests/ValueStringBuilder.Insert.Tests.cs	Added tests verifying culture-specific formatting and InvariantCulture default behavior

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Joy-less]

It's a good change, but I will mention that this is a binary-breaking change due to changing the signature of Append<T> and Insert<T>. It also changes the default from CurrentCulture to InvariantCulture. It might have made more sense to publish as v4.0.0.

[linkdotnet]

I am fair to maybe change the default back to CurrentCulture for the time being. That is sensible (and change it in v4 entirely).

While it is a ABI breaking change, it is not from a source code compilation point of view. That is "good enough" for me. Also reflection doesn't work, I do understand.

Anyhow, let me change the default back to CurrentCulture

[Joy-less]

OK. In the future, I would recommend updating the major version instead of the minor version when making binary-breaking changes. I had to update my packages to use the latest version of ValueStringBuilder to prevent missing method calls.
:)

[linkdotnet]

I'll keep that in mind. Can you explain your workflow? Especially:

I had to update my packages to use the latest version of ValueStringBuilder to prevent missing method calls.

If you update as a direct or transient dependency that should work without issue. Your workflow seems more advanced that ABI compatibility is needed

[Joy-less]

I'll keep that in mind. Can you explain your workflow? Especially:

I had to update my packages to use the latest version of ValueStringBuilder to prevent missing method calls.

If you update as a direct or transient dependency that should work without issue. Your workflow seems more advanced that ABI compatibility is needed

I actually have multiple packages that depend on ValueStringBuilder, in particular:

1. JsonhCs
2. BigReal

Since the first package depends on the second package, when I updated ValueStringBuilder in the first package, it broke the dependency of the second package. This meant I had to update everything to the latest version of ValueStringBuilder in order to use the latest version.

[linkdotnet]

Okay fair enough - sorry for that

[Joy-less]

Okay fair enough - sorry for that

It's no worries - problem fixed, I just suggested for the future to avoid breaking changes or bump major version :)