Adds raw string alternatives to auto converted unicode strings
Helps avoid data loss while converting LFS-encoded strings

Why did I add such feature?
It gives us more precision and control over the bytes that we receive from and send to InSim. More specifically: to avoid data-losses caused by unicode conversion.

I was using LfsUnicodeEncoding2 with an LfsEncodingChecker class that would do a round-trip to check if there is a data loss while using GetString and GetBytes. It worked totally fine as long as the bytes that I received were valid LFS-encoded strings. Someone had manually saved their cfg.txt and it converted some of the Japanese characters in their nickname (Ply Name in cfg.txt) into UTF-8 replacement characters �, which got encoded as EFBFBD, which isn't a valid sequence in LFS-encoded strings. LfsUnicodeEncoding2 would fall back to ? for EFBF, then round-trip would make it 3F (ASCII question mark), which would make my checker warn about the data-loss.

Related forum thread:

In Japanese code page, LFS displays EFBF sequence as a square (no match) and BD as ｽ.

I didn't test all the changes but these packets seem to work fine: IS_NCN, IS_NPL, IS_CPR, IS_TOC, IS_BTN. I used both unicode strings and raw bytes in my code; they worked fine together.