Dict key normalization can trigger "key value cannot be read" errors

[petervwyatt]

Due to TestGrammar PoC needing to do dictionary key normalization (via key sorting, so that all PDF libraries process keys in the same order so output is deterministic and independent of PDF library), under certain rare but specific conditions this can result in "key value cannot be read" errors since the normalized key name is not the same as the PDF. This appears to occur when the name uses multiple adjacent # hex codes - and likely where the PDF library is assuming it is UTF-8 when it is not. Most PDF libraries hide any # hex codes so the key name returned is whatever C/C++ type the library chooses and how they map back to a key inside the PDF (with appropriate hex codes) is a mystery...

A possible solution is for the Arlington PDF wrapper to store both the "raw" key name returned/used by the PDF SDK (in whatever format it uses), as well as the normalized version used by TestGrammar PoC for sorting (std::wstring).