Refactor string encoding to be consistent and more memory efficient

[PaulusParssinen]

In this PR:

• Merged WriteResponse with WriteDirect. Same logic.
• Made ASCII encoding consistent across the overloads.
  • More specifically, there were couple overloads in CustomFunctions that called underlying WriteSimpleString with the buffer length calculated using Encoding.ASCII.GetByteCount, while in RespWriteUtils the parameters were assumed to be well formed ASCII. In my opinion, there's couple options here;
    1. either all public methods that feed input into ASCII encoding should be changed to do the "proper" Encoding.ASCII.GetByteCount calculation (it's tiny bit overhead: a fast path doing vectorized scan for any invalid ASCII and depending on the output falling on slow path)
    2. keep current behaviour and trust the input
    3. offer two set of overloads, other maybe internal and explicitly documented to expect well formed ASCII
• Renamed overloads such as WriteBulkString to WriteAsciiBulkString to make it clear to caller the underlying assumptions of the API.
  • The previous logic checked the available buffer space using the assumption that the input was well formed ASCII, and then formatted the input using Encoding.UTF8.GetBytes (which can expand string of x characters up to 3*(x+1) bytes). So I also changed the logic to use Encoding.ASCII.GetBytes. If we want to format UTF8 strings as bulk strings, we can add WriteUtf8BulkString overload with correct length checks.
• Added WriteUtf8BulkString overload to fix Char that occupy multiple bytes in string as key or value would make GarnetClient.ExecuteForStringResultAsync() unable to continue execution. #236
  • note: This logic can be optimized by common pattern used by serializers where calculating maximum buffer sizes is often cheapr than calculating exact sizes. However because we need to encode the exact size as ASCII digits, there's isn't straightforward way to do that here. (as always, variable length elements are annoying in serialization).
• Now thanks to earlier renaming, safely skip intermediate array allocations and instead encode & copy in WriteAsciiDirect or WriteAsciiBulkString
• Also move more constant strings in .data section using the u8-literals to avoid repeated re-encoding

Fixes #236