feat: Make Status ToString() methods format consistent

[HarleyRossetto]

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

Provide links to any issues in this repository or elsewhere relating to this pull request.

N/A

Describe the solution you've provided

The different Status structs that expose internal state of the client have different formatted when string-ified. If the state is logged or otherwise serialised as a string it is not possible to determine what the values mean without understanding the underlying types. This change aligns 3 status ToString() methods to follow a consistent format, including labelling for the different fields exposed.

---

The BigSegmentStoreStatus struct returns data in the format (Available={0},Stale{1)} injecting the fields in allowing the type to be easily string-ified.

DataSourceStatus and DataStoreStatus only output a string of the internal fields without labels, making decoding the results difficult without understanding the details of these types.

e.g.
DataStoreStatus(True,False)
DataSourceStatus(Initializing,4/10/2026 10:42:08 PM,)
or
DataSourceStatus(Initializing,4/10/2026 10:42:08 PM,UNKNOWN(Connection refused (localhost:5279))@4/10/2026 10:42:18 PM) when errors are present.

DataSourceStatus is reasonably understandable as is, however DataStoreStatus is not.

This change adds in the labelling of fields so they can be clearly understood when using the default ToString() implementation.

BigSegmentStoreStatus has also been updated to include its type name like the other two status providers. Now all follow the pattern set by the other two providers: Type(Field=Value,Field2=Value...).

(Available=False,Stale=False)
to
BigSegmentStatus(Available=False,Stale=False)

Also include minor changes to ErrorInfo's ToString() method to utilise character append overloads for single characters rather than string variation as it is a cheaper call.

Describe alternatives you've considered

I considered applying this logic to ErrorInfo's ToString(), however the output of that is fairly clear and can be understood without additional labels.

Additional context

Test coverage was ignored as no existing tests exist for these methods, and they are not utilised by the SDK itself.

---

Note

Low Risk
Only affects ToString() output (logging/diagnostics), with minimal behavioral risk beyond potentially breaking code/tests that assert exact string formats.

Overview
Makes the string representations of status structs consistent and self-describing by updating ToString() in BigSegmentStoreStatus, DataSourceStatus, and DataStoreStatus to include the type name and Field=Value labels.

Also makes a small micro-optimization in DataSourceStatus.ErrorInfo.ToString() by using StringBuilder.Append(char) for single-character separators.

^{Reviewed by Cursor Bugbot for commit a1df382. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Reviewed by Cursor Bugbot for commit ad283f7. Configure here.}

[jsonbailey]

@HarleyRossetto the changes have been released in LaunchDarkly.ServerSdk: v8.12.0. Thanks for the contribution.