Runtime crash when a .NET Standard 2.0 library using Utf8StringWriter is used in a .NET Standard 2.1 project

[ZimM-LostPolygon]

I am creating a .NET Standard 2.0 library that's using Utf8StringWriter<ArrayBufferWriter<byte>>. That library is supposed to be consumed by other projects with possibly newer .NET versions. The problem here is that for .NET Standard 2.0 builds of Utf8StringWriter, a shimmed version of ArrayBufferWriter is used, because that class was only introduced in .NET Standard 2.1:
https://github.com/Cysharp/Utf8StringInterpolation/blob/main/src/Utf8StringInterpolation/ArrayBufferWriter.cs

What happens is when the library is consumed by project that uses .NET 6.0 for example, and that project also has Utf8StringInterpolation added as a package, the compiled project as a whole will use the version of Utf8StringInterpolation that doesn't include the copy of ArrayBufferWriter that's inside the Utf8StringInterpolation assembly. The result is crash in runtime:

Unhandled exception. System.TypeLoadException: Could not load type 'System.Buffers.ArrayBufferWriter`1' from assembly 'Utf8StringInterpolation, Version=1.3.1.0, Culture=neutral, PublicKeyToken=df4c250b14d82627'.

In general, it's bad practice to pollute the the BCL namespaces with public types... A simple solution to this problem would be to simply change the namespace of the copy of the ArrayBufferWriter class and removing the conditional compilation, so it's available under all .NET versions as a fallback. Otherwise this breaks binary compatibility.

[neuecc]

Oh, Polyfill should be internal.
I didn't check it carefully when I merged the PR.
I'll fix it right now.

[neuecc]

Hmm, but I don't want to provide my own ArrayBufferWriter...
To be honest, I think the best thing to do is to remove the netstandard 2.0 support again.

[ZimM-LostPolygon]

If I may ask, please consider not removing it, at least fully. Even if the user has to provide their own implementation of IBufferWriter (which is what I ended up doing anyway), it's still immensely useful.