Remove one string allocation in XmlTextEncoder by using stackalloc span and TryFormat

[TrayanZapryanov]

Replace several int.ToString("X", NumberFormatInfo.InvariantInfo) by using stackalloc char[] and Tryformat.

[TrayanZapryanov]

I am not sure if 8 is the correct value here.

[ghost]

Tagging subscribers to this area: @dotnet/area-system-xml
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Replace several int.ToString("X", NumberFormatInfo.InvariantInfo) by using stackalloc char[] and Tryformat.

Author:	TrayanZapryanov
Assignees:	-
Labels:	area-System.Xml, community-contribution
Milestone:	-

[stephentoub]

We had a long discussion about this one in #61774.

[TrayanZapryanov]

We had a long discussion about this one in #61774.

Okay I will close this PR, but let's discuss one idea that popup in my mind for this if you see some value in it.
What about creating a class which inherits TextWriter(also receives another TextWriter in ctor) and keeps inside small char. Then this class is used everywhere instead of current one. Biggest benefit of it will be that all inherited methods will write to this buffer and when it reach its maximum - flush it to the underlying writer either through it's write "string" or "char[]" or even ReadOnlySpan methods.
Also this class can provide methods similar to ValueStringBuilder - at least giving us a span , so we can use it to format value types. From my previous checks of the code I see that all int/datetimes... are formatted as strings through XmlConvert which converts them to strings. Instead now it will write them to the Span provided from new class.

@stephentoub, @krwq

[krwq]

@TrayanZapryanov I'm ok with making any experimentation if you can see large perf potential benefit. Make sure to write some reasonable benchmarks covering all common scenarios. Technically such TextWriter doesn't really need any changes to the current code as you can technically use it in your own code so perhaps even if this finds useful for very narrow scenarios it might be more of a blog post rather than change and people mind find it useful. I'd suggest start with opening an issue explaining more the idea and if you got some time for experimentation go ahead and share your code and benchmarks used (ideally open an issue once you got some results). Worst case scenario we will not find any benefit and not change anything and close the issue.