Finish (mostly) erradicating StringBuilder marshaling from corefx (dotnet/coreclr...

Finish (mostly) erradicating StringBuilder marshaling from corefx (dotnet/coreclr#33780)

* Finish (mostly) erradicating StringBuilder marshaling from corefx

This should finish my quest of removing StringBuilder marshaling from coreclr and corefx, which I've strived to do because it often adds unnecessary overhead and often is done incorrectly because of intricacies in how the marshaling works; while not using it often leads to `unsafe` code at call sites, there's much less magic, and it affords the ability to optimize more if desired.

There are still three remaining [Out] StringBuilder's in Interop.Odbc.cs, which I've not removed because tests are limited and the call graph to these is non-trivial with StringBuilders passed through.  There may also be a few straggling DllImports I missed while scouring interop that's not following our guidelines of being in src\Common\.

Other than those, the remaining StringBuilder usage I found in DllImports was for [In] only, and in those cases it's reasonable, as the call sites are building up StringBuilders and then passing them off to the call sites; converting those to use `char*` or similar could actually make them more expensive.  I did, however, ensure they were properly annotated as [In], in order to make the intent clear and avoid potential marshaling costs for the unnecessary [Out] direction.

Where I was touching a function in one of these stray interop files that was duplicated elsewhere, I also consolidated it to a centralized location, but I've not in this PR done the cleanup work for the rest of the files.

* Address PR feedback

* Address further feedback

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Commit migrated from https://github.com/dotnet/coreclr/commit/2755ed0f497f68a9a879b174ef81747f09e9be43